hi all, Thanks for driving this. I fully support moving to a fixed 3+2 schedule to eliminate our constant release alignment discussions. Christmas is wonderful, but honestly, Lunar New Year is my personal favorite. I guess Diwali is also a favorite for many of our core maintainers.
Hence, my two cents is a 5 / 3.5 / 3.5-month split: Release 1: Early May target (KIP freeze in late Feb) Release 2: Late August target (KIP freeze in mid-June) Release 3: Early December target (KIP freeze in early Sept) If we apply 3+2 policy to the current 4.4.0 schedule, it naturally pulls the code freeze forward to July 20. This allows us to target late August for 4.4.0, making it a perfect fit for "Release 2" and smoothly clearing September for the next KIP freeze Best, Chia-Ping 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 > > >
