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:
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.
(One caveat is that I don't actually use the : notation with Git myself, but I think I understand it.)
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.
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.
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.
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.
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.