Skip to content
This repository has been archived by the owner on Oct 4, 2023. It is now read-only.

Release procedure

Jump to bottom
Nathan Hammond edited this page Aug 31, 2018 · 30 revisions

Release procedure

Loom typically issues a release about every 2 weeks. To create a new release:

Creating a release

  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 "prerelease-x.y.z". Typically you will branch from the tip of the development branch, but you should branch from an old release if you are creating a patch for that release.
  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. Make an annotated tag on the final commit on the master branch, with the message "Release {your version}", e.g. git tag -a 0.5.3 -m 'Release 0.5.3'
  11. Push the tagged commit to the release branch.
  12. Merge the release branch back into "development" branch to capture release notes and any other useful changes.
  13. If this is the highest release version, merge release branch back into "master".
  14. Verify release artifacts
Clone this wiki locally