Release procedure

Release procedure

1. Choose the new release version number x.y.z according to the semantic versioning standard. (Prior to 1.0.0, for backward-incompatible changes increment y. For backward-compatible changes or patches increment z. After 1.0.0, for backward-incompatible changes to API, increment x. For backward-compatible changes, increment y. For patches, increment z.)
2. Create a release branch "x.y.z-prerelease". Typically you will branch from the tip of the master branch, but you should branch from an old release if you are creating a patch for a release that has diverged from master.
3. Update release notes in "doc/releasenotes.rst"
4. Ensure that documentation is up to date
5. Tag the commit as "{x.y.z}rc1", e.g. "0.5.3rc1". Creating a tag will cause Jenkins to create a release and deploy to PyPi. PyPi will not allow you to upload the same version twice, so always use rc prerelease versions until you are ready for an official release. Start "rc1", and increment the rc number with each new prerelease.
6. Push to the prerelease branch with "--tags".
7. Jenkins (jenkins.loomengine.org) should automatically build packages, run smoke tests, upload the release candidate to PyPi, and verify the PyPi release.
8. If testing reveals problems, increment the version rc#, submit changes to the prerelease branch, tag with a new rc#, and repeat as needed.
9. Once a release is created, it cannot not be changed (PyPi won't let you), so be sure that you are ready before proceeding!
10. Create an annotated tag on the release branch, with the message "Release {your version}", e.g. git tag -a 0.5.3 -m 'Release 0.5.3'
11. Verify release artifacts

• Tag created in https://github.com/StanfordBioinformatics/loom
• Documentation with the correct version published to https://readthedocs.org/projects/loom/
• Tagged docker image published to https://hub.docker.com/r/loomengine/loom/
• Four packages published to PyPi: loomengine, loomengine_utils, loomengine_server, and loomengine_worker

1. Merge the release branch back into "master" branch to capture release notes and any other useful changes. If merging is not possible because master has significantly diverged, use cherrypick.