Release checklist

This is being done for 1.0.0, but it can be reused for later releases.

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

• Instructions how to install from scratch
• Is the cherry-picking advice for beta releases the best idea?

Things that need to happen before the release can be made

• Set estimated release date
• Testing
• Put out a call for testing on pumpio@pumpit.info
• Possibly upgrade one or two E14N nodes?
• Write instructions for upgrading

Things to do when the code is ready for release

• Update docs' prose, if necessary

  • README.md prerequisites
  • README.md colophon
  • Manpage text
  • Change log

• Run npm version (updates all version numbers and the manpage timestamp, then commits and tags)

• Git push

• npm run fullbuild

• npm publish

• Update http://pump.io

• Update GitHub Releases (TODO: this should be automated)

• Update relevant parts of the wiki (install instructions) or move them to readthedocs

• Update installation instructions in readthedocs (or version it?)

• Pumpit.info/pumpio note about the release

• Upgrade E14N 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

• Prepare change log entries on master
• Have package.json version end with -beta.N where N is the beta iteration (starting at zero)
• 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 with the exact desired version number
• Run npm version on the beta branch
• When npm publishing, make sure to publish to the beta dist-tag

Initial beta releases

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

Beta updates

• 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

• Before release, prepare change log entries on master and cherry-pick to beta
• Commit version number changes (i.e. dropping the -beta.N suffix/bumping the semver patch number) on the release branch

Initial releases

• To release, 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)

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 in addition to beta