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

Name release branches just after major.minor #10013

Merged
merged 1 commit into from
Jun 8, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions changelog.d/10013.misc
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
Simplify naming convention for release branches to only include the major and minor version numbers.
8 changes: 4 additions & 4 deletions docs/dev/git.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.)
Expand All @@ -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)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this example doesn't really ring true anymore?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. I'm inclined to rewrite some other parts of that section (and regenerate the graph, etc.), but I didn't want this PR to fall victim to scope creep. Do you have any preferences for what should be in scope for this PR?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, re-reading it I might rethink this though. With the caveat in the previous sentence of "we've had two release in flight" than it does make sense that release-v1.2 would be more stable than release-v1.3.

I guess I'm a bit nervous someone will read the second sentence and draw absolute claims...

Copy link
Contributor Author

@callahad callahad Jun 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's leave well enough alone and get back to this as part of the more general docs overhaul happening as part of the move to mdbook?

2 changes: 1 addition & 1 deletion scripts-dev/release.py
Original file line number Diff line number Diff line change
Expand Up @@ -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():
Expand Down