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 Oct 19, 2017 · 30 revisions

Release procedure (version >= 0.6.0)

Loom typically issues a release about every 2 weeks. To create a new 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 "x.y.z-prerelease". 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. Start with prerelease "x.y.zrc1", and increment the rc number with each new prerelease. PyPi will not allow you to upload the same version twice, so use rc prerelease versions until you are ready for an official release.
  4. Set the version using "build-tools/set_version.sh {version_and_rc}".
  5. Update release notes in "doc/releasenotes.rst"
  6. Ensure that documentation is up to date.
  7. Run unit tests with "loom test unit".
  8. Commit.
  9. Tag the commit as "{x.y.z}rc1", e.g. 0.5.3rc1
  10. Push to prerelease branch with "--tags".
  11. Build packages with build-tools/build_loom_packages.sh
  12. Upload to PyPi with build-tools/pypi-upload.sh
  13. Run integration tests: Give the tag to the testing team. Launch and run a workflow in local and google cloud.
  14. If testing reveals problems, submit changes to the prerelease branch, tag with a new "rc{#}", and repeat tests.
  15. Once a release is created, it cannot not be changed (PyPi won't let you), so be sure that you are ready before proceeding!

If this is the highest available release version (usually True):

  1. Merge the prerelease branch into master. (This should be a fast-forward merge! Otherwise you need to repeat tests before tagging the release.)
  2. 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'
  3. Push the tagged commit: "git push origin master --tags"
  4. Build packages with build-tools/build_loom_packages.sh
  5. Upload to PyPi with build-tools/pypi-upload.sh
  6. Verify the new version is available on PyPi for loomengine, loomengine_server, loomengine_utils, and loomengine_worker. You can see available versions using "pip install loomengine==; pip install loomengine_server==; pip install loomengine_utils==; pip install loomengine_worker==;"
  7. Verify that the release shows up in github.
  8. Verify a corresponding Docker image is built and published on Dockerhub.
  9. Verify that documentation was published to readthedocs.
  10. Merge master into development branch. (This might not be fast-forward, if anything was merged into development since you created the release branch. That is ok.)

If this is NOT the highest available version but a patch release on an older version (rarely True)

  1. Make an annotated tag on the final commit on the prerelease branch, with the message "Release {your version}", e.g. git tag -a 0.5.3 -m 'Release 0.5.3'
  2. Push the tagged commit: "git push origin {{prerelease branch}} --tags"
  3. Build packages with build-tools/build_loom_packages.sh
  4. Upload to PyPi with build-tools/pypi-upload.sh
  5. Verify the new version is available on PyPi for loomengine, loomengine_server, loomengine_utils, and loomengine_worker. You can see available versions using "pip install loomengine==; pip install loomengine_server==; pip install loomengine_utils==; pip install loomengine_worker==;"
  6. Verify that the release shows up in github.
  7. Verify a corresponding Docker image is built and published on Dockerhub.
  8. Verify that documentation was published to readthedocs.
  9. In order to capture useful bugfixes and release notes, merge the prerelease branch into the development branch, but be careful not to roll back version numbers on the development branch.

Release procedure (version < 0.6.0)

Loom typically issues a release about every 2 weeks. To create a new 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 "x.y.z-prerelease". 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. Increment the version in "doc/conf.py"
  4. Increment the version in "loomengine/VERSION"
  5. Update release notes in "doc/releasenotes.rst"
  6. Ensure that documentation is up to date.
  7. Run unit tests with "loom test unit".
  8. Commit.
  9. Tag the commit as "{x.y.z}-prerelease-rc1"
  10. Push to prerelease branch with "--tags".
  11. Run integration tests: Give the tag to the testing team. Launch and run a workflow in local and google cloud. (The default docker image won't exist until after you create the release, so you must use "-e LOOM_DOCKER_IMAGE=loomengine/loom:{x.y.z}-prerelease-rc1")
  12. If testing reveals problems, submit changes to the prerelease branch, tag with a new "-rc{#}", and repeat tests.
  13. Once a release is created, it must not be changed, so be sure that you are ready before proceeding!

If this is the highest available release version (usually True):

  1. Merge the prerelease branch into master. (This should be a fast-forward merge! Otherwise you need to repeat tests before tagging the release.)
  2. 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'
  3. Push the tagged commit: "git push origin master --tags"
  4. Verify that the release shows up in github.
  5. Verify a corresponding Docker image is built and published on Dockerhub.
  6. Verify that documentation was published to readthedocs.
  7. Merge master into development branch. (This might not be fast-forward, if anything was merged into development since you created the release branch. That is ok.)

If this is NOT the highest available version but a patch release on an older version (rarely True)

  1. Make an annotated tag on the final commit on the prerelease branch, with the message "Release {your version}", e.g. git tag -a 0.5.3 -m 'Release 0.5.3'
  2. Push the tagged commit: "git push origin {{prerelease branch}} --tags"
  3. Verify that the release shows up in github.
  4. Verify a corresponding Docker image is built and published on Dockerhub.
  5. Verify that documentation was published to readthedocs.
  6. In order to capture useful bugfixes and release notes, merge the prerelease branch into the development branch, but be careful not to roll back version numbers on the development branch.
Clone this wiki locally