Daniel James wrote:
We could use a more complicated branching scheme to merge the changes back into the main branches.
My old suggestion was (still is) that we could use a dedicated 'release' superproject branch for the releases, avoiding the need to freeze master. When starting a release, the release manager would `git merge master` into `release`, then potentially cherry-pick "update foo" master commits as needed (the bot would need to be changed to not compress more than one change into a single commit.) The same `release` branch would then be used for the point release in the same manner - cherry-pick commits to superproject `master`. When I first suggested it, the problem point was that the testers would have to test `release` as well which would either waste time (as it would seldom change) or require a smarter infrastructure that doesn't re-test the branch unless it changes. But we don't rely that much on the testers nowadays, so this would be less of an issue.