Releasing a new CKAN client - HebaruSan/CKAN GitHub Wiki
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...
- 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.
CKAN releases are mostly automated, but the full process is:
- Update the release number in the changelog. Releases should have an even release number. The Minor version number must be updated if the release includes any changes to the Spec
- Go to draft a new release, fill in the version (don't forget the leading
v
; egv1.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.
- 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 and push the release number to the next odd integer.
- Congratulate yourself on a job well done!
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.