Proposed stable branch discipline

Internals
1

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
2

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.

3

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.

4

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.

5

thanks for the awesome information.

6

Oh, ugh. Suffering now. It turns out that the repo-manager-app does its work in part by looking for a dominator (that is, a shared ancestor on every ancestor path) of master and release. Since release is now a merge commit with stable, this dominator is now the root of the whole repo. Merging later would not have caused this problem. But here we are now. I think I have code that can solve this problem, but getting this working is going to be a pain. Should have seen this coming, sigh.

7

In future releases, I'm editing the release instructions to do the merge -s ours stable just before the final build. The challenge of making the repo-manager-app work reliably is one reason, but I also have a certain dislike for the current asymmetry that the cherry-picked commits wind up on a slightly different chain (meh, sort of) than the main commits. Anyway, I think this will avoid the problem that we saw on this release.

8

Oh... having our cake and eating it too. I can put the merge commit just before the final "update the version number to v8.8" commit, so we get the property that you wanted of having the released commit have a sensible commit message.

1 Like