Skip to content
This repository has been archived by the owner on Apr 22, 2024. It is now read-only.

Release Management

Jump to bottom
Adam Butler edited this page Mar 20, 2019 · 1 revision

Aether should have the ability to release images on a regular basis for the purpose of testing and deployment. The management of these images should be tied directly to our version control scheme. For this purpose, we adapt the gitflow method.

The one important deviation we make from standard gitflow is to build releases directly from their individual release branch. We don’t maintain a master branch at all, just a series of release branches tied to a feature constrained version series. All feature development happens in feature branches, which branch either from develop or from a release branch. Release branches will live for as long as they are officially supported.

For example, a release-2.3 branch is created from develop at the point which we think we have all the features we need for version 2.3. We perform bugfixes on branches created from release-2.3. Once the bugfix work is finished, there should be a PR to merge to release-2.3. Merging this PR into the release-2.3 branch will trigger the creation of new 2.3.0-rc Docker images that are then pushed to Docker Hub.

N.B. the process of building Docker files and pushing them to Docker Hub is handled by Travis, which runs the release script.

At the point where we’re comfortable calling the candidate finished, we tag the head of the release branch with the correct version. The tag should be in the format x.y.z, where x.y match the branch name, and z starts at 0 and is incremented for each bugfix release; in our example, the tag would be 2.3.0.

After the release of 2.3.0 we have two situations to account for:

  1. If we want to create new features, but not break anything, we could create a new release branch called release-2.4.
  2. If we have to address a bug in release 2.3, we branch from release-2.3, and fix the issue. This branch should have PRs back to all three active branches: release-2.3, and if the bug is relevant, release-2.4 and develop. If this PR addresses the bug, we can tag the head of release-2.3 with 2.3.1, thereby triggering a new build and push to Docker Hub.

Note that each time we tag a release branch and release a new image, we need to start building rc images for the next version. So if I tag the head with 2.3.1, any PRs that are merged to the release-2.3 branch should trigger builds of 2.3.2-rc. The aforementioned release script handles this by creating and managing a file called VERSION that it increments every time a release is made.

Once 2.4 is complete, we have the option of no longer supporting 2.3 and suggesting users upgrade to the newest dot version, 2.4. Because of this, bugfix branches should originate with the oldest branch that a) has the bug and b) is still supported.

So we have two types of builds:

  1. Release candidate builds from each merge to a release branch (e.g. 2.3.7-rc)
  2. Official releases, triggered by tagging a release branch (e.g. 2.3.7)

Both of these are built automatically by Travis and pushed to Docker Hub.

Clone this wiki locally