OpenCloud
/
MatrixSynapse
mirror of https://github.com/matrix-org/synapse
1
0
Fork 0
Code Issues Releases Wiki Activity

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: Dan Callahan <danc@element.io>
pull/10141/head
Dan Callahan 2021-06-08 11:44:50 +01:00 committed by GitHub
parent c842c581ed
commit 7dc14730d9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 6 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
changelog.d/10013.misc Normal file
View File

@ -0,0 +1 @@
Simplify naming convention for release branches to only include the major and minor version numbers.

8
docs/dev/git.md
View File

@ -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: that our active branches are ordered thus, from more-stable to less-stable:
* `master` (tracks our last release). * `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>. id="a3">[3](#f3)</sup>.
* PR branches which are targeting the release. * PR branches which are targeting the release.
* `develop` (our "mainline" branch containing our bleeding-edge). * `develop` (our "mainline" branch containing our bleeding-edge).
* regular PR branches. * regular PR branches.
The corollary is: if you have a bugfix that needs to land in both 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` *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`, 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 `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 release-branch, we can of course cherry-pick it, but landing it in the release
branch first helps reduce the chance of annoying conflicts.) 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 <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, 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)

2
scripts-dev/release.py
View File

@ -139,7 +139,7 @@ def run():
click.get_current_context().abort() click.get_current_context().abort()
# Switch to the release branch. # 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) release_branch = find_ref(repo, release_branch_name)
if release_branch: if release_branch:
if release_branch.is_remote(): if release_branch.is_remote():