Hi Matthias, Thanks for leading a discussion on release dates. I think it will go a long way to help with planning and delivery with a more concrete schedule. I agree with Andrew for 3 releases with the 3+2 schedule.
-Bill On Wed, May 27, 2026 at 3:44 AM Andrew Schofield <[email protected]> wrote: > Hi Matthias, > Thanks for driving this. I'm a bit less concerned about it than you, but > stronger rules would eliminate the typical release schedule alignment > discussions we've seen in all of the recent releases. > > I would go for 3 releases of equal lengths in March, July and November. I > favour the 3+2 schedule. > > Thanks, > Andrew > > On 2026/05/27 05:43:04 "Matthias J. Sax" wrote: > > Hello, > > > > I would like to start a discussion about our time-based release > > schedule. We have a discussion (that I personally find a little bit > > annoying and tedious) about release plan dates on every single release > > (the 4.4.0 discussion, is just another example). And we still often end > > up with none-optimal time-frames (4.4 might also be an example here -- > > not by itself, but the impact on 4.5 release timeline -- cf my latest > > reply on the other thread). > > > > Given that we actually plan to have time-based releases, I think we > > should agree on a more fixed schedule, which allows us to project all > > release dates (including KIP/feature/code freeze) into the future and > > just be done with it. -- And even if we need an exception from the rule, > > we can easily get back on track on future release afterwards. > > > > I was also looking into historic data, and while we overall don't do too > > bad to stay on track for 3 release per year, we had to pay the price of > > a few short release cycles to "shift back" (the previous 4.3 release is > > a good example of it), while we still did shift somewhat forward > > overall. These short releases cause even more pain IMHO. > > > > To avoid problems with the holiday season end of the year, I would like > > to propose the following fixed release cadence (this is not my personal > > favorite, but let's start here): > > > > 1. KIP freeze is the second Wednesday of January, May, and September. > > 2. Feature freeze = KIP freeze + 3 weeks. > > 3. Code freeze = Feature freeze + 3 weeks. > > 4. Release target = Code freeze + 4 weeks. > > > > While we never officially formalized the 3+3 weeks between KIP/feature > > and feature/code freeze dates (and we used shorter time windows in the > > past, ie, 2+2 weeks), 3+3 established itself since 4.0 release -- I am > > totally open for other time frames, but believe we should not go shorter > > than 2+2 weeks. I would also not make them longer than 3+3, as it would > > just give us the subjective impression that releases are closer to each > > other. > > > > A 3+2 schedule would actually be my personal preference. For KIPs, > > giving only 2 weeks to complete them is tight, even for simple KIPs. And > > for bug-fixes, I would believe that 2 weeks are enough. Making it > > overall 5 week instead of 6, also helps to keep releases 1 week "further > > apart" from each other (not really, but we know how reality works, given > > our subjective nature). > > > > The above schedule implies that we would have target release dates late > > March, July, and November. Even if we need more than 4 weeks after code > > freeze, we still have some head room in the November release before the > > holidays (we might hit Thanksgiving, but I think that's ok). For the KIP > > freeze in January, it should also give enough time after the holidays to > > complete KIPs and get them accepted (w/o being too close to the > > holidays, eg, "first Wednesday in January" would effectively mean, that > > KIPs must get voted before the holiday break). > > > > If we want to take the holiday season into account even more, we could > > also make the timeline between "release 3" and "release 1 of the > > following year" two weeks longer, and the other two timelines 1 week > > shorter. This would give us the following KIP freeze deadlines: > > > > - third Wednesday of January > > - second Wednesday of May > > - first Wednesday of September > > > > It also implies, that Thanksgiving would be less of an issue for > > "release 3". This schedule is what I would personally prefer, instead of > > an 100% equal distribution of our 52 weeks across all three releases. > > > > > > > > For the upcoming 4.4 release, we should make it a 5-month cycle > > targeting October instead of September, and we would also have a > > slightly longer cycle for 4.6, which we should only start in January. > > However, starting with 4.6 we would enter the above proposed fixed > > timeline, putting us into a much better position going forward IMHO. > > > > > > Looking forward to your thoughts on this idea. > > > > > > -Matthias > > > > > > >
