Skip to content

Releases

Jump to bottom
Paul Lorenz edited this page Aug 13, 2020 · 1 revision

Release Patterns

The Next Release

Work for the next release should be targeted to the release-next branch. When we want to release, the work from this branch will be merged to master, triggering CI to make a release.

The reasons to use release-next instead of release-<some.version.number> are:

  1. The next version number may change, either because we want to bump the major or minor version, or because there's an intermediate release.
  2. If we use release-next, developers know what to target by default, instead of looking for a constantly changing branch name.
  3. We can make release-next the default branch, so that PRs automatically target that branch.

In general release-next should always be releasable, since everything in that branch should have come through an approved PR. There are some common exceptions:

  1. Release notes may be incomplete. Since pulling in updated foundation/fabric/edge dependencies may pull in unrelated work, the release notes may be updated separately from the PR pulling in the changes.
  2. CLI support may be incomplete. Same as above: the CLI changes may come in a separate PR from the dependency update. At some point we'll push the CLI pieces into their respective projects and this will be improved.

Note that even though work may be done in a staged fashion, if the stages are being merged into master branches, the stages should always be releasable.

Hotfix to Latest Release

If we want to push out a quick and for whatever reason don't want to push what is in release-next a hotfix branch can target master directly.

Hotfix to a Previous Version

If no hotfixes have been made to the version before, we must first create a release branch.

  1. Find the tag for the latest build of that version.
  2. Create a release branch from that tag
  3. Create fix branch off that release branch
  4. Target a PR back to the release branch
  5. When the PR is merged, it will create a release.

For example, if a patch needs to made to 0.12, here's how you could create the release branch.

~/work/nf/ziti$ git tag | grep 0.12
v0.12.0
v0.12.1
v0.12.2
v0.12.3
v0.12.4
~/work/nf/ziti$ git co v0.12.4 -b release-0.12.x
Switched to a new branch 'release-0.12.x'
~/work/nf/ziti$ git push -u origin release-0.12.x

If a release branch already exists, you would branch off that release branch and proceed from there.

Clone this wiki locally