Based on the current documentation and practice, releases happen roughly according to the following schedule:
Tag
How long after branch
X.1.0-rc1
3 days
X.1.0-rc2
2 weeks
X.1.0-rc3
4 weeks
X.1.0
6 weeks
X.1.1
8 weeks
X.1.2
10 weeks
X.1.3
12 weeks
X.1.4
14 weeks
X.1.5
16 weeks
X.1.6 (if necessary)
18 weeks
Barring exceptional cases and dependent on the generosity of the release managers (@tobiashieta@tstellar), there might be releases later than that, but between first and last GA release, that means a given LLVM version is maintained for about ~12 weeks = 3 month.
That is pretty much exactly half of the lifetime of a given version, i.e. until LLVM X+1 comes along. With my distributor hat on, my concern about this is that there’s about a 3 month period where we’re telling users who happen to find a regression “sorry, wait for the next version”.
It would be nice IMO if the same amount of patch releases could be distributed more evenly over the lifecycle of an LLVM version, such that the window where the response to a regression is “” gets reduced. The idea is not to increase the work of the release managers.
What I have in mind would be something as follows:
Tag
How long after branch
Increment
X.1.0-rc1
3 days
-
X.1.0-rc2
2 weeks
~2 weeks
X.1.0-rc3
4 weeks
2 weeks
X.1.0
6 weeks
2 weeks
X.1.1
8 weeks
2 weeks
X.1.2
10 weeks
2 weeks
X.1.3
14 weeks
4 weeks
X.1.4
18 weeks
4 weeks
X.1.5
22 weeks
6 weeks
X.1.6 (if necessary)
28 weeks
6 weeks
The idea is to keep the RC phase and the first two patch releases unchanged at 2 week increments (in order to be able to react reasonably quickly to issues that occur), and then start drawing out releases progressively. This should coincide nicely with a slow-down in bugs being found, which would also go some ways towards alleviating complaints (example) that certain subprojects see no changes between patch releases, yet are expected to build new binaries.
Of course, this schedule is not intended to preclude faster releases if a critical issue needs a faster response, but it would basically ensure a smoother “handover” between LLVM X and LLVM X+1, and hopefully ensure a higher-quality X.1.<last_patch> which ends up percolating into various places (and staying there) for a long time.
I had similar thoughts during the LLVM 18 cycle. I didn’t feel great about saying no to a fix knowing that it was going to be months until another release came out.
I do think waiting 6 or even 4 weeks for another point release is too long and may discourage people from using the releases. I appreciate that you are trying to save the release managers work, but if we were to extend the support life for the release, I’d rather keep the 2 week cadence and just do more releases. Doing a release is much easier now that we have so much automation, the most time consuming part is triaging, reviewing, and merging the fixes.
Yeah I have had similar thoughts as well. The only downside I see (personally) is that the period I have to be “on the release” will be prolonged. But I guess the triaging and reviewing will slow down quite a bit after a while. I hope that people reviewing fixes can continue to do so. Without that it’s much harder to do a release.
Maybe we can extend the 19.x release to another 2-3 releases and see how that feels and how much engagement we get after a while.
I agree that we should extend the release cycle. On the Rust side, we usually accumulate a handful of additional backports between the last upstream release and the start of the RC cycle for the next version. This is unfortunate, because other distributors of LLVM likely want these patches as well.
An additional complication is that that there are many late adopters who will only start testing a new LLVM version once the GA version is released and distributed, so bugs from certain sources only start rolling in once we’re already late in the release cycle.
So yeah, I think it would be good to extend the release cycle a bit. I think 3 extra releases would bridge us to the next RC phase, if the release managers are up for that. I wouldn’t extend support until the next GA, at least initially, to avoid having two releases in flight at the same time.
In the past, I heard users complain about that long period without backports (especially those users who have experience with LTS software in the rest of their stack), and I think your proposal addresses that nicely.
Thanks!
Yeah, I imagine that the bar for a backport at the end of a cycle would be quite high so there should be few of them.
But, I imagine that managing releases is a huge commitment, should the workload be spread to more people? (Not volunteering! But of course I’m always happy to help with reviews)
Sounds like the proposal then is to extend the number of releases with 3 adding 6 weeks to the release cadence. I support this and think we can implement that for 19 already.
I think we might want to update the documentation describing a bit better what things we will take as back ports in the different “phases” of an release. But that might be a different RFC.
Should we first try this out and see how it goes, before making commitments? I understand the motivation, but I’m worried about increased load on release managers.
To put it another way, I’d reject this RFC if release managers feel that increasing the load contributes to burnout in a significant way. I prefer the status quo (assuming it’s sustainable) over commitments the community won’t able to fulfill.
Anything past X.1.5 could be on an as-needed basis IMO. Already just a realistically surmountable bar for patch releases in the latter half of the lifecycle would be a great benefit IMO, even if not every 2 week increment yields enough patches to justify a release.
Inversely, it would be cool to commit to a last release ~24 weeks after branching[1], just to mop up any remaining fixes, and regardless of how many or how few patch releases came in between.
” gets reduced. The idea is not to increase the work of the release managers.