Releases and PR merge timing

Development
1

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:

  1. No active release candidate (first to second Tuesday)
  2. 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?

2

I think the policy is pretty clear.

PRs merged before the RC make it into RC and get released.

For bugfixes, we don’t backport them to the RC unless it’s a bug that makes the RC unusable/unreleasable, or it’s significantly game breaking that we adhoc deem the urgency to release it.

3

I guess my question is more relevant to what goes into the second (or later) RC.

I understand your answer to mean “it’s always okay to merge”. I’d just need to worry about it when actually merging a deal-breaker bugfix.

4

I think currently we are more on what’s described here: https://forum.syncthing.net/t/thoughts-on-our-release-process/15704/11. In essense no “scary changes” in the two weeks after rc.1, then an rc.2 with all the changes (except the scary ones), then one more week of testing, then release. Just that there’s no hard and fast rule on it, that process is manual.

5

Yeah what imsodin said. It’s slightly subjective and up to the releaser. This time rc2 was a couple of days late because reasons, but regardless when i do it I generally follow the line of commits up to and including safe seeming fixes and stop at features or major changes.

PRs are merged whenever ready with no consideration to the release process.

If there are important bug fixes exceptions will be made as appropriate. There have been some rc2s with cherry picked fixes and such, so it’s not necessarily the case that merging a feature will make everything after that point off limits. Human judgement applies.

6

Thanks for the clarifications. Especially that post / discussion from a year ago is a very interesting read and helps a lot. The essence of it should be added to the docs por favor! :wink: And I agree that renaming the tags to -beta and -rc would help to understand the cycle. Even better, some prominent location to show the current “development phase”.

Still not quite clear on the automatic translation updates. What’s the schedule there and how do we make sure they end up in the release, even if just translated a day before final release tagging?

That’s the answer I needed, thanks. I don’t think I will be the one merging “scary” PRs anytime. So I can hit merge on #8091 now? Unless one of you wants to review and have the final word.

7

Another way to think of it would be that after -rc.1 was tagged, all development should be handled as if happening on the release branch, so it’s obvious there are no big changes going in. In that sense, main is hopping between two different characteristics every two weeks, while I’d expect the two phases to just happen on different branches. Like the master and next stuff happening for Linux e.g.

8

Yeah except in practice we don’t do that, and if it turns out we should have then we can cherry pick around the damage at RC time. So I wouldn’t worry about phases or whatnot when merging PRs. And we have a fairly high threshold for what’s scary nowadays…

Translation imports happen every week, on Monday I think, so are likely to happen just before RCs.

9

You mean we don’t make merging decisions based on the relase cycle?

IMO, anything that extends the release description / change-log and is not a recent regression or otherwise important bugfix, should not go into the release between -rc.1 and later RCs.

Translation updates are the opposite of scary. They should be pulled as close as possible to the release. And in that case, you’ll need to make sure these go into the release branch, if others are free to merge features on main for the following release anytime. I couldn’t tell from previous observation if that’s applied consistently.

Thanks for explaining the situation.

10

I think that’s been discussed in the thread linked above: Basically everything is inteded to go in, unless it would result in a minor version bump or otherwise is obviously problematic/needs lots of testing. Reason being that it’s bad if a bugfix takes almost 2 months to get released. just because it happened to be merged right after rc.1. I still think this is the right choice.

1 Like
11

Correct.