Release Process

Overview

The “master” branch always contains the latest stable version. All development work happens in “dev” or feature branches, until it’s time for a release. This release process is based on the one here.

Releasing

When a release becomes imminent, all features going into the release are merged into a new branch named with the major version number of the release (e.g. 0.2, 0.3, …. ):

  $ git checkout -b 0.x dev
  $ git merge nifty-feature
  $ git push origin 0.x

Testing and bugfixes are done continuously in this branch until it’s considered working and correct. Be sure that all references in the tutorial to static files (images) on github point to those files in the release branch. The release branch is then merged (without fast-forwarding) into “master”, tagged with its release number, and sent to github:

  $ git checkout master
  $ git merge --no-ff 0.x
  $ git tag -a 0.x
  $ git push origin master
  $ git push origin : 0.x

After a release, continue development in “dev”:

  $ git checkout dev

Fixing bugs in a release

If bugs are found in the release, switch back to that release branch, squash the bugs, then merge the fixes into master (assuming no other release has been done in the mean time), and tag as a new release with a bumped minor version number (e.g. 0.2.1, 0.3.7, …):

  $ git checkout 0.x
  ... squash-bug...
  $ git commit
  $ git push origin 0.x
  $ git checkout master
  $ git merge --no-ff 0.x
  $ git tag -a 0.x.y
  $ git push origin master
  $ git push origin : 0.x.y

Minor changes to a release

If minor changes need to be made, the process is identical to fixing a bug in a release. A change is minor if it doesn’t invalidate the released version of the tutorial. Rewording a paragraph would be a minor change. Changing the parameters of a script that the tutorial depends on would be a major change. If a major change is necessary, you must do a full release and bump the major version number.