This repository has been archived by the owner on Oct 4, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 8
Release procedure
Nathan Hammond edited this page Jun 2, 2017
·
30 revisions
Loom typically issues a release about every 2 weeks. To create a new release:
- 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.)
- 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.
- Increment the version in "doc/conf.py"
- Increment the version in "loomengine/VERSION"
- Update release notes in "doc/releasenotes.rst"
- Increment the "LOOM_DOCKER_IMAGE" setting to the new version in default settings files "loomengine/client/settings/gcloud.conf" and "loomengine/client/settings/local.conf".
- Ensure that documentation is up to date.
- Run unit tests with "loom test unit".
- Commit and push to prerelease branch.
- 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}")
- If testing reveals problems, submit changes to the prerelease branch and repeat tests.
- Once a release is created, it must not be changed, so be sure that you are ready before proceeding!
- Merge the prerelease branch into master. (This should be a fast-forward merge! Otherwise you need to repeat tests before tagging the release.)
- 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'
- Push the tagged commit: "git push origin master --tags"
- Verify that the release shows up in github.
- Verify a corresponding Docker image is built and published on Dockerhub.
- Verify that documentation was published to readthedocs.
- 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.)
- 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'
- Push the tagged commit: "git push origin master --tags"
- Verify that the release shows up in github.
- Verify a corresponding Docker image is built and published on Dockerhub.
- Verify that documentation was published to readthedocs.
- In order to capture useful bugfixes and release notes, merge the prerelease branch into the development branch.