# Proposed stable branch discipline

**URL:** <https://racket.discourse.group/t/proposed-stable-branch-discipline/1453>\
**Category:** Internals\
**Created:** [November 11, 2022, 9:25pm UTC](https://racket.discourse.group/t/proposed-stable-branch-discipline/1453 "2022-11-11T21:25:02Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![LiberalArtist](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/liberalartist/32/151_2.png) [@LiberalArtist](https://racket.discourse.group/u/LiberalArtist)\
**Post date:** [November 12, 2022, 9:14pm UTC](https://racket.discourse.group/t/proposed-stable-branch-discipline/1453/3 "2022-11-12T21:14:16Z")

</div>

This looks good to me!

(One caveat is that I don't actually use the `:` notation with Git myself, but I think I understand it.)

Re:

> [@Racket v8.7 Release Thread](https://racket.discourse.group/t/racket-v8-7-release-thread/1343/22):
>
> Thinking about this a bit more. I kind of like the fact that currently, the `master` branch has a single thread. I realize that merge commits that are made with merge -s ours don't represent "real" dependencies, but that's not obvious unless you dig into the commits and see that the merge has no diff. So I'm inclined to drop back to the "merge-with-the-release-branch-when-its-created" strategy. I'd really like to hear from others, though. @samth ? @mflatt ?

I don't have a strong opinion; I can see advantages on both sides. If we did opt to merge `stable` into `master`, you have a good point that we should probably edit the commit message to be explicit that it's a "fake" merge.

But actually, I think we don't need to make a final decision until after this release. Once you push `v8.7` and `stable`, we'll presumably see this effect @elibarzilay pointed out:

> [@Racket v8.7 Release Thread](https://racket.discourse.group/t/racket-v8-7-release-thread/1343/10):
>
> One thing that I've noticed (~two days ago) is that due to merges going only from `master` to `release` to `stable` but not the other way, GH shows `stable` as being way ahead of `master`.

If that creates noise in the UI or it otherwise seems desirable to do the "merge-stable-into-master-after-release" variant, we could do `git switch master && git merge -s ours stable && git push` any time before branching for the 8.8 release. Otherwise, we do nothing and stick with the "merge-with-the-release-branch-when-its-created" strategy.

On this part:

> [@jbclements](#):
>
> One obvious alternative to the workflow that I'm proposing here would be to perform the `merge -s ours stable` on the release branch just before the tag is applied. I don't really have a strong opinion on which is better.

I agree it doesn't seem like a big deal either way, but I think I slightly prefer having `git merge -s ours stable` at the beginning of the release branch rather than the end so that the tag and branch end up pointing to a commit like [Update version number for the v8.5 release · racket/racket@9d228d1 · GitHub](https://github.com/racket/racket/commit/9d228d16fb99c274c964e5bef93e97333888769f) with a nice message rather than a fake merge commit.

---

_[View the full topic](https://racket.discourse.group/t/proposed-stable-branch-discipline/1453)._