Release checklist

Put your ideas in the "Brainstorming" section if you don't know when they should be done. If you know when, put it directly in the corresponding section. Feel free to reorder items in each section (things to be done first go upper). Eventually, Brainstorming will become empty and the list will be time-ordered :)

Brainstorming

• Is the cherry-picking advice for beta releases the best idea?

Pre-release tasks

• Testing
• Put out a call for testing on your personal instance
• Possibly upgrade one or two public nodes?
• Write instructions for upgrading for semver-major releases
• Update installation instructions in readthedocs (or version it?)

Post-release tasks

• Send a note about the release
• Tweet about the release?
• Invite to upgrade public nodes
• Contact maintainers of prominent nodes?

Release channel notes

tl;dr: master is considered the latest alpha, the latest beta is on the beta branch, and each stable release gets its own maintenance branch. Changes are propagated with merges when it makes sense, otherwise cherry-picks are used. Change log entries are always added on master and then merged/cherry-picked into other branches; version number bumps happen only on the relevant branch.

Alpha/nightlies

• Push to master
• Have package.json version end with -alpha.0
• Bump semver-major as necessary
• Don't ever publish to npm

Beta

All releases

• Update docs' prose, if necessary
  • README.md prerequisites
  • README.md colophon
  • Manpage text
  • Change log
• Prepare change log entries on master
• Merge
  • See below - this depends on the type of release
  • When resolving package.json conflicts keep the "version": line that came from master (this is because if you modify it to have the desired version number, npm version will refuse to run)
• Run npm version (updates all version numbers and the manpage timestamp, then commits, tags and pushes) - have package.json version end with -beta.N where N is the beta iteration (starting at zero)
  • Run npm version with the exact desired version number
  • Run npm version on the beta branch
  • npm publish
• npm publish --tag beta
• Update GitHub Releases (TODO: this should be automated)
• Announcement mailing list post

Initial beta releases

• To merge, checkout beta and perform a merge from master

Beta updates

To merge:

• Prepare fixes on master
• If it's possible to merge master to beta without introducing unwanted changes, then do so - otherwise cherry-pick relevant commits (including the change log update)

Release

All releases

• Update docs' prose, if necessary
  • README.md prerequisites
  • README.md colophon
  • Manpage text
  • Change log
• Follow release-dependent instructions (see below)
• Run npm version (updates all version numbers and the manpage timestamp, then commits, tags and pushes)
  • Do this on the release branch
• npm publish
• Update GitHub Releases (TODO: this should be automated)
• Announcement mailing list post

Initial releases

• Prepare change log entries on master and cherry-pick to beta
• Branch A.B.x off the beta branch, where A is the major version and B is the minor version (do not indicate patch version in the branch name)
• Bump semver-minor on master (don't use npm version)
• Enable Travis branch cronjob for Docker

Patch releases

• When pushing patch releases, commit the fix to master then cherry-pick the commit to the release branch
• Cherry-pick the change log update to the release branch