Does Github offer the option to create release-page for a project? I've noticed it let you create different tag for the source, but couldn't find the UI/web where I can add release notes, built package(s) and all that.
Update 2d July 2013, you now can define a release.
Releases, a workflow for shipping software to end users.
Releases are first-class objects with changelogs and binary assets that present a full project history beyond Git artifacts. They're accessible from a repository's homepage:
Releases are accompanied by release notes and links to download the software or source code.
Following the conventions of many Git projects, releases are tied to Git tags. You can use an existing tag, or let releases create the tag when it's published.
You can also attach binary assets (such as compiled executables, minified scripts, documentation) to a release. Once published, the release details and assets are available to anyone that can view the repository.
That is what replaces the old binary upload service, which was removed in December 2012!
Initial answer (February 2012)
Not that I know of: this is very dependent of each project language and release management process.
One way would be to use the README.md to publish those information, or to link to the release notes as a separate document.
The nice detail about a link is that it can, since a few weeks, be a relative one (see blog post "Relative links in markup files").
Related
Is there a way to automatically update the "Releases" version number on a Github page? Either from automatic machinery within Github, or using some API to update it?
(See the release number "3.5.0" in the image below...) Thanks.
This sidebar component shows you the latest release (I believe). If you want to add a release, that can be done using the REST API. You can also update the release using the REST API.
Note that it isn't sufficient to just push a tag here. A release on GitHub is associated with a tag, but it can also have a message and assets (usually binaries or source code) associated with it. You do need such a tag, but you also need to create the actual release on GitHub.
If you want an example of how this can be done with shell scripting, Git LFS has a script that performs this task as part of the release process.
Does anyone know what is the difference between a GitHub release and the actual release that software company announces?
I'm trying to find the different versions of vue.js, on the vue.js official website there are only two versions but on the GitHub repository many releases I was wondered if the two concepts are different?
Release(may be downloadable link) version is just file which is uploaded.
Just they decide to provide only two version(may be latest) on official site.
It is all. If same version, (should be) same file. It is just like top selling tag on a store.
When they release a GitHub version, it is supposed to be open source. The one the company releases may have more code they have not reeased yet or is confidential.
We have a group-developed metadata conventions document for a particular group of ocean models stored as github-flavored markdown at https://github.com/ugrid-conventions/ugrid-conventions
and now we would like to "release" the current version of this markdown document at version 1.0 (and continue the development of the conventions for future releases).
I understand that github has releases, but we don't want a zip file containing the markdown document, we just want a "version 1.0" markdown document. We could also like to preserve the changes so that people can see what changed relative to previous versions as we go forward.
Should we just copy the existing document ugrid-conventions.md to ugrid-conventions_v1.0.0.md, or is there a better way?
I'd suggest creating a tag for each release. Tags automatically get listed on GitHub's Releases page (in fact, every Release is associated with a tag), and you can also link directly to files within a tagged commit. For example, if you created a tag named v1.0, you could send folks to https://github.com/ugrid-conventions/ugrid-conventions/blob/v1.0/ugrid-conventions.md to see the 1.0 version of that file.
Is there a way to automatically generate a change log from Github issues?
Ideally I want to be able to point at a closed milestone and generate either a plain text list of closed issues with their titles or, even better, a list with markup for links to the issues and the title of the issues themselves.
You can try to use Github-Changelog-Generator. (I'm author of this project)
It generates changelog from tags and merged pull-requests.
This script also have a support of GitHub Issues.
This changelog was generated by this script. CHANGELOG.md
Example:
Changelog
1.2.5 (2015-01-15)
Full Changelog
Implemented enhancements:
Use milestone to specify in which version bug was fixed #22
Fixed bugs:
Error when trying to generate log for repo without tags #32
Merged pull requests:
PrettyPrint class is included using lowercase 'pp' #43 (schwing)
support enterprise github via command line options #42 (glenlovett)
This isn't for Github specifically, but through Git you can run the log through pretty print to generate a changelog style html page.
From https://coderwall.com/p/5cv5lg
git log v2.1.0...v2.1.1 --pretty=format:'<li> view commit • %s</li> ' --reverse | grep "#changelog"
You can use the GitHub API to get a list of issues associated with a given milestone.
For example:
curl https://api.github.com/repos/<user>/<project>/issues\?milestone\=1\&state\=closed
replace <user> and <project> with the username and project and this will return a json list of all closed issues of the milestone with the id 1. You can then, for example, use a script to extract the information you are interested. Here is a python example that prints the list of issues as restructured text:
import json
with open("issues.json") as of:
data = json.load(of)
for issue in data:
t = issue['title']
n = issue['number']
url = issue['html_url']
print "* %s [`Issue %s <%s>`_]" % (t, n, url)
See if the following tool will do for you github-changes.
Disclosure: I'm the author of the tool.
We created an open source project to generate changelog from the list of closed github issues since a given datetime. It's available here: https://github.com/piwik/github-changelog-generator
Not directly through GitHub: that would be a kind of hook that you could put in place, and which would based on naming convention or comment convention that your project might follow.
Even using the issues title isn't always a sure way to generate meaningful change log, unless you review and edit if needed each and every issue title of your project.
In other words, it is very dependent on how you manage your project and not easily generalized to all GitHub repos.
I said as much in a very similar question "Publish a project release (binary/source packages) on Github?".
In addition of a third-party solution (or a GitHub Action like generate-changelog), you might soon Q3 2021, have a native feature from GitHub:
One of the most important parts of the software lifecycle is releasing your code for others to consume.
GitHub Releases will make that even easier by providing compelling and automatic release notes.
When creating a Release, you can click a button to automatically generate release notes.
If you want something more custom, you can a REST API to get the generated release notes and integrate them into your existing releases process.
We also want to ensure that these release notes look amazing when a maintainer shares them and make them easier to discover. We have done a complete redesign of releases to make projects announcements look stunning.
We are surfacing these releases in the feed to increase discovery.
We are also improving the open graph data for releases so they look equally fantastic when shared off of the GitHub platform.
Intended Outcome
Our number one goal is to make it easy for maintainers to create great release notes so more people can discover that amazing work maintainers are doing.
With minimal effort many projects will be able to benefit from detailed release notes.
For maintainers who put more time into their release notes to write editorialized content the intended outcome is that we free up time they are currently spending to maintain custom infrastructure and compile a changelog so they can focus on the most important content for their customers, high quality editorialized content.
Our other goal is to ensure that the release notes look great and are something maintainers and developers are excited to read and share.
How will it work?
The new Releases UI will be able to be enable with feature preview
A new button in the Release creation UI will be able to be pressed to generate release notes from any tag
The generated notes will be able to be configured via a .github/release.yml
A new REST API will allow customers to generate notes at their own convenience to further automate and customize the experience with GitHub actions.
I helped build a jQuery plugin for this recently that uses GitHub issues to communicate app updates directly to the user. The repo can be found here https://github.com/uberVU/github-changelog
Usage is pretty simple:
$(function() {
var $demoChangelog = $('.demo-changelog');
//call the plugin on a dom none
$demoChangelog.changelog({
//give it a repo to monitor
githubRepo: 'uberVU/github-changelog-playground',
});
//manually check for new closed issues
$('.demo-button').on('click', function(e) {
e.stopPropagation();
$demoChangelog.changelog('checkForUpdates');
});
});
I have been using an open source Java project and had to make some custom changes for our site. I have downloaded the source code via Subversion, modified two files and built a custom JAR file. Now I need to store these custom changes into OUR Subversion source control system. What is the best way to do this?
Should I check the entire tagged version of the open source code into our system and then create a branch with our change in it? Or should I just check-in our custom files and rely on the open source tagged version to always be around? Or perhaps something else altogether?
Take a good look at Subversion vendor branches, which are meant for "maintain[ing] custom modifications to third-party data in your own version control system". This sounds like exactly what you want. You would create a vendor branch for the open source Java project in your main repo (from their last SVN revision before your modifications). Then, check in your modifications. In the future, you can merge in upstream changes.
The Subversion book is free and available online, with a section devoted to choosing a repository layout.
the Subversion community recommends
that you choose a repository location
for each project root—the “topmost”
directory that contains data related
to that project—and then create three
subdirectories beneath that root:
trunk, meaning the directory under
which the main project development
occurs; branches, which is a directory
in which to create various named
branches of the main development line;
and tags, which is a collection of
tree snapshots that are created, and
perhaps destroyed, but never changed.
I'm happy to elaborate if you are having trouble determining what exactly this means for your project.
First try to avoid this as long as you can, if it is possible try to get your changes into the open-source project (less work for your self in the future...)
But if that was not a option, I would follow Matthew Flaschen advice about vendor branches.