Skip to content
AJ Jordan edited this page Jul 14, 2017 · 20 revisions

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?

Things that need to happen before the release can be made

  • Testing
  • Put out a call for testing on [email protected]
  • Possibly upgrade one or two E14N nodes?
  • Write instructions for upgrading for semver-major releases

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, tags and pushes)

  • npm publish

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

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

  • Pumpit.info/pumpio note about the release

  • Tweet 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

  • Commit version number changes (i.e. dropping the -beta.N suffix/bumping the semver patch number) on the release branch

Initial releases

  • Before release, prepare change log entries on master and cherry-pick to beta
  • 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
Clone this wiki locally