Proposed stable branch discipline

Following discussion with @elibarzilay and @LiberalArtist , I think we're proposing a slightly revised discipline on the handling of the stable branch. Specifically, here are two excerpts from the release checklist:

At branch time:

* Cut the release branch from master
    {Run: git push origin master:release
          git pull
          git checkout release
          git merge -s ours stable}

At release time:

    Merge the release branch to stable, delete release branch.
    This should be a ff merge, because we merged stable to release earlier.
    {Run: cd $RKTWORK/checkout; git checkout release; git pull ; git checkout stable ; git pull}
    {Run: git merge --ff-only release}
    {Run: git checkout master}
    {Run: git branch -D release}
    {Run: git push origin :release}
    {Run: git push origin stable}

Does this sound reasonable? Am I missing something, obvious or otherwise?

1 Like

Oh! Obvious question: why would we do this?

The existing mechanism had us create a merge between the tagged release and the stable branch, meaning that the commit associated with the stable branch was not the same as the release tag.

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.

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:

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:

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:

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 with a nice message rather than a fake merge commit.

Yep, agreed with all, I believe. One thing this discussion has highlighted for me is that there's some nontrivial stuff going on when you ask for merge-bases or compute "commits ahead", and that you can fudge this in weird ways with merge -s ours.

thanks for the awesome information.