summary refs log tree commit diff
diff options
context:
space:
mode:
authorDan Callahan <danc@element.io>2021-06-08 11:44:50 +0100
committerGitHub <noreply@github.com>2021-06-08 11:44:50 +0100
commit7dc14730d925a39a885a14ce309d99054f9617d5 (patch)
tree245c19599fdae8a9e832c3f88e92f8cb8a2d58da
parentWhen joining a remote room limit the number of events we concurrently check s... (diff)
downloadsynapse-7dc14730d925a39a885a14ce309d99054f9617d5.tar.xz
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>
Diffstat (limited to '')
-rw-r--r--changelog.d/10013.misc1
-rw-r--r--docs/dev/git.md8
-rwxr-xr-xscripts-dev/release.py2
3 files changed, 6 insertions, 5 deletions
diff --git a/changelog.d/10013.misc b/changelog.d/10013.misc
new file mode 100644
index 0000000000..9d164d9ce2
--- /dev/null
+++ b/changelog.d/10013.misc
@@ -0,0 +1 @@
+Simplify naming convention for release branches to only include the major and minor version numbers.
diff --git a/docs/dev/git.md b/docs/dev/git.md
index b747ff20c9..87950f07b2 100644
--- a/docs/dev/git.md
+++ b/docs/dev/git.md
@@ -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)
diff --git a/scripts-dev/release.py b/scripts-dev/release.py
index 1042fa48bc..fc3df9071c 100755
--- a/scripts-dev/release.py
+++ b/scripts-dev/release.py
@@ -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():