Hi devs, I need some clarification please on the strategy for when to merge PRs. There is a clear and documented release cycle, with stable version X on the first Tuesday of the month, and candidate version (X+1)-rc.1 a week later. So there are effectively two phases:
- No active release candidate (first to second Tuesday)
- Release candidate testing (second Tuesday to next month)
I wonder when it’s appropriate to merge PRs. If we want a strictly linear history, only the first period would allow merging features. In the second period, only bug-fixes should be committed to the release branch. But it seems the release branch seldomly departs from main, but is usually just behind. There is no cherry-picking and no merging back release into main.
As an example, I was surprised to see #8108, #8133 and #7972 merged as new features when we were already past -rc.1 time. Then two days later, -rc.2 was tagged, but on the commit before these three merges. OTOH, #8144 seems clearly like a bugfix that I would have expected to still go into the current release cycle, and therefore on the release branch (or at least cherry-picked there, with a new rc ASAP to get some testing).
I actually held off merging #8091, although deemed ready, because it was past -rc.1 time already. If I had done it, the build fixes (#8134, #8135, #8126, #8123) and translation updates would have been based on it and we’d either need to cherry-pick them on
release, or accept #8091 going into the release as well. So is there a consensus or undocumented schedule for when PRs are okay to merge, or why didn’t we wait to merge the above mentioned three feature additions until v1.19.0 will be released?
Especially the automated translation update commits always go to main and merging features after -rc.1 will make it harder to get them released. Maybe I’ve just never seen a release branch with independent commits, or it was purposefully managed to hold off PRs while in the rc period.
What I’d like is to freely hit merge on PRs once ready without looking at the forum header for where we are in the release cycle. But that means there would need to be more cherry-picks and merge commits from release back into main. I wouldn’t mind a slightly less linear Git history, but the impression is that a strictly linear Git history is much preferred. Just trying to understand who makes the decisions what goes into rc versions and when they are made, and how that affects feature development work.
If there is already a clear policy, could it be added to the developer documentation please?