RFC: LLVM Releases every two weeks

[tstellar]

Introduction

I would like to propose some changes similar to RFC: Distribute patch releases over lifecycle of an LLVM version. I think we had general agreement on that RFC and we did a trial with the LLVM 19 release cycle, which seemed to work well, so I’d like to officially come to an agreement on the new process so we can document it and everyone is aware of it.

Proposal

I would like to propose that we do an LLVM release approximately every two weeks. This means that we would extend our biweekly X.1.Z releases up until 1-3 weeks before (X+1).1.0-rc1.

Using the LLVM 20 cycle as an example, the schedule would look like this:

Tag	Time since release/20.x branch	Increment
20.1.0-rc1	3 days	-
20.1.0-rc2	2 weeks	~1.5 weeks
20.1.0-rc3	4 weeks	2 weeks
20.1.0	6 weeks	2 weeks
20.1.1	8 weeks	2 weeks
20.1.2	10 weeks	2 weeks
20.1.3	12 weeks	2 weeks
20.1.4	14 weeks	2 weeks
20.1.5	16 weeks	2 weeks
20.1.6	18 weeks	2 weeks
20.1.7	20 weeks	2 weeks
20.1.8	22 weeks	2 weeks
20.1.9 (If Necessary)	24 weeks	2 weeks
21.1.0-rc1	~25 weeks	~1.5 weeks

The goal of this schedule is to ensure that there is no large gap between when upstream support for one release ends and the next release cycle begins. With our previous release schedule, we would stop doing bug fix releases ~8 weeks before the next major release and this created a gap where our releases were essentially unsupported, making it difficult for users that ran into bugs during this time.

This new schedule purposely does not overlap the two release cycles. This was done to encourage users to ‘use the main branch’ as we usually say or in this case ‘use the latest release’. Also, coordinating two releases at once might be difficult, so I wanted to avoid doing that if we don’t have to.

Let me know what you think.

[h-vetinari]

Thanks for the RFC! As a downstream vendor, I spend quite a bit of time building patch releases, and so I still think (like the previous RFC your referenced) that it would make sense to increase the 2 week window in the latter half of the 6 month. I assume other third party builders might be in a similar camp.

OTOH, I’d be broadly in favour of another idea that came up in the LTS thread:

@thesamesam

What I do want to see that I didn’t make explicit enough: ideally, we would have overlap of a month or two (up to .2 or .3) perhaps.

IOW, extend N.1.x until {N+1}.1.2 is out. Both points (whether individually or together) would make me prefer 4 weeks increments after N.1.4 (or 5).

The main argument being: it’s much more important to have a ship vehicle for bug fixes that’s not just “next major release”, than it is to roll out those fixes ~right away (which is what 2 week increments work out to be in practice).

[Endill]

@h-vetinari

IOW, extend N.1.x until {N+1}.1.2 is out.

While this is an idea I can support, first I’d like to see commitment to do the work from our current release managers, or someone stepping up to become a release manager.