Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Releasing a new CKAN client
When merging pull requests
Merging pull requests is a great time to update
CHANGELOG.md. You can do this as a separate commit on master, but with a bit of git-fu you can update it as part of the merge commit itself!
$ git checkout master $ git merge someuser/somebranch --no-commit --no-ff # This merges your PR, but doesn't commit it. $ vim CHANGELOG.md # Or whatever your favourite editor is, if not vim. $ git add CHANGELOG.md $ git commit -m 'Merge #<PR-Num> <Description>' # This commits the merge, *and* your changes to CHANGELOG.md $ git push
This has the advantage that if the merge is undone, so is the changelog entry.
Making sure the changelog is up-to-date is important for our next step, which is...
Before the release
- Build the final code base and test that CKAN will launch on both Windows and Linux, will install, remove and update mods.
- Ideally, create a Pre-release first and ask the @MacOS-Testers and @Wranglers teams to try the new client and report any issues.
Making a release!
CKAN releases are mostly automated, but the full process is:
- Go to draft a new release, fill in the version (don't forget the leading
v1.2.3), and title (which is a cool release name of your choosing).
- We traditionally have a release picture that relates to the title. The textbox at the bottom lets you upload a picture. While it looks funny, you can use the standard
[title](url)markdown syntax to make a link, except instead of a title you have a the image reference (
!(url...)). If you're unsure, look at the text of a previous release to see what it looks like.
- Have a line of three dashes (
---) by themselves, with a blank line on either side, after the release image. The updater program expects to see this, so it doesn't include the image in the text-only release notes.
- Copy'n'paste in the release notes for this version, usually from the changelog. Add extra notes if necessary.
- Add another line of three dashes, and provide attribution for the release image. Again, the updater program expects to see this.
- Hit the release button and celebrate!
You do not need to build the binary. Travis will see the new tag, build a binary, run it through tests, and upload the assets when complete. Once they're uploaded, the client updater will show a new release is available to users and ask if they wish to upgrade.
After the release
- Update the IRC channel topic with the version of the new release.
- Update the forum thread topic with the version and date of the new release.
- Post in the forum with release notes and a link to the releases page.
- Start a new "unreleased" stub in the changelog file.
- Congratulate yourself on a job well done!
Improvements that can be made to the release process
Right now the release project requires a human to copy'n'paste in a changelog, which is silly, because that could be done by a bot. In the future the ideal release process would simply be choosing a release name and image, and having bots do the rest.