Skip to content
Snippets Groups Projects
Unverified Commit 7dc14730 authored by Dan Callahan's avatar Dan Callahan Committed by GitHub
Browse files

Name release branches just after major.minor (#10013)


With the prior format, 1.33.0 / 1.33.1 / 1.33.2 got separate branches:

    release-v1.33.0
    release-v1.33.1
    release-v1.33.2

Under the new model, all three would share a common branch:

    release-v1.33

As before, RCs and actual releases exist as tags on these branches.

This better reflects our support model, e.g., that the "1.33" series had
a formal release followed by two patches / updates.

Signed-off-by: default avatarDan Callahan <danc@element.io>
parent c842c581
No related branches found
No related tags found
No related merge requests found
Simplify naming convention for release branches to only include the major and minor version numbers.
......@@ -122,15 +122,15 @@ So, what counts as a more- or less-stable branch? A little reflection will show
that our active branches are ordered thus, from more-stable to less-stable:
* `master` (tracks our last release).
* `release-vX.Y.Z` (the branch where we prepare the next release)<sup
* `release-vX.Y` (the branch where we prepare the next release)<sup
id="a3">[3](#f3)</sup>.
* PR branches which are targeting the release.
* `develop` (our "mainline" branch containing our bleeding-edge).
* regular PR branches.
The corollary is: if you have a bugfix that needs to land in both
`release-vX.Y.Z` *and* `develop`, then you should base your PR on
`release-vX.Y.Z`, get it merged there, and then merge from `release-vX.Y.Z` to
`release-vX.Y` *and* `develop`, then you should base your PR on
`release-vX.Y`, get it merged there, and then merge from `release-vX.Y` to
`develop`. (If a fix lands in `develop` and we later need it in a
release-branch, we can of course cherry-pick it, but landing it in the release
branch first helps reduce the chance of annoying conflicts.)
......@@ -145,4 +145,4 @@ most intuitive name. [^](#a1)
<b id="f3">[3]</b>: Very, very occasionally (I think this has happened once in
the history of Synapse), we've had two releases in flight at once. Obviously,
`release-v1.2.3` is more-stable than `release-v1.3.0`. [^](#a3)
`release-v1.2` is more-stable than `release-v1.3`. [^](#a3)
......@@ -139,7 +139,7 @@ def run():
click.get_current_context().abort()
# Switch to the release branch.
release_branch_name = f"release-v{base_version}"
release_branch_name = f"release-v{current_version.major}.{current_version.minor}"
release_branch = find_ref(repo, release_branch_name)
if release_branch:
if release_branch.is_remote():
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment