Picking up our recent discussion, I thought the release candidate testing phase was meant to catch exactly this kind of situation? Bugs introduced found in the new version should be fixed before it is declared final.
I was quite aware of that regression, so tried to be quick when reviewing #8147 and #8157 so the fixes could be picked up before release. So how can we make sure such things do get picked up? Have some label for “release-critical” PRs? Let co-maintainers manage the release branch as well, not only main via PRs?
I feel quite confident with using Git in general, but the branching / release model for Syncthing always has me thinking twice and is obviously error-prone. What I learned from the other thread (don’t base merging decisions on release timing) is all good. But in the opposite direction, when handling a release, merges since the last -rc tag should definitely be skimmed for cherries to be picked IMHO. Even better, cherry-pick regression fixes to the release branch right after they are merged on main, then tag the next -rc.X.