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.