> "Anyway, all I want to say is that the original schedule was hard to follow. The codebase is large and CVEs are common these days."
As an occasional contributor I can confirm this. From my POV committers/maintainers are having a challenging task to keep up, especially while trying to juggle around with multiple release branches/versions (trunk/4.5.0, 4.4.0, 4.3.2, 4.2.2). Best regards, Dejan S. https://github.com/dejan2609 On Tue, Sep 29, 2026 at 7:55 AM Chia-Ping Tsai <[email protected]> wrote: > Hi Andrew, > > +1 to the revised 4.5.0 schedule. I would not pull it a week earlier, > since that puts the KIP freeze right after the holidays. > > Regarding the 4.6.0 schedule, I think we could discuss it once 4.5.0 > reaches code freeze. We had too many must-have changes in 4.4.0, which > caused a serious delay. I try to review all backports but my tokens are > limited :) > > Anyway, all I want to say is that the original schedule was hard to > follow. The codebase is large and CVEs are common these days. > > Best, > Chia-Ping > > > On 2026/09/25 08:36:23 Andrew Schofield wrote: > > Hi, > > I'm starting to look at the release schedule for 4.5.0. > > > > In Chia-Ping's table from 29 May 2026, we have: > > > > Version : KIP Freeze : Feature Freeze : Code Freeze : Target Release > > 4.4.0 (planned) : Jun 17, 2026: Jul 8, 2026 : Jul 22, 2026 : Aug 19, 2026 > > 4.5.0 : Oct 7, 2026 : Oct 28, 2026 : Nov 11, 2026 : Dec 9, 2026 > > 4.6.0 : Mar 3, 2027 : Mar 24, 2027 : Apr 7, 2027 : May 5, 2027 > > > > In reality, 4.4.0 ran 3 weeks later than this. Matthias suggested a KIP > freeze of Jan 13, 2027 which gives this. > > > > 4.4.0 (actual) : Jul 8, 2026: Jul 29, 2026 : Aug 12, 2026 : Real soon now > > 4.5.0 (revised): Jan 13, 2027 : Feb 3, 2027 : Feb 17, 2027 : Mar 17, 2027 > > 4.6.0 : Mar 3, 2027 : Mar 24, 2027 : Apr 7, 2027 : May 5, 2027 > > > > I think we could even pull 4.5.0 a week earlier than that, but I don't > think there's anything fundamentally wrong with a short 4.6.0 provided > people know in advance. > > > > Are people happy with the 4.5.0 (revised) dates above? Would a week > earlier be better given that it gives an extra week to 4.6.0 which is > looking very squeezed? > > > > Thanks, > > Andrew > > > > On 2026/09/16 04:01:41 Chia-Ping Tsai wrote: > > > Hi all, > > > > > > +1 to the 4.5 schedule, given the delay of 4.4.0. > > > > > > I think having 4.5 land right on Lunar New Year should be fine this > time, since "too close" is the real issue here. > > > > > > Best, > > > Chia-Ping > > > > > > > Matthias J. Sax <[email protected]> 於 2026年9月16日 清晨7:05 寫道： > > > > > > > > I don't think we have for 4.5... I believe that there was a slight, > high level agreement for the long term, that we want to follow the > "calendar week proposal"? > > > > > > > >>>>>> KIP freeze would be Wednesday's, weeks 9 / 25 / 41, with > feature freeze > > > >>>>>> +3 weeks, and code freeze +2 weeks. > > > > > > > > AK 4.4 KIP freeze was Jul/8. > > > > > > > > For 2026, week 41 would be Oct/7 which is way too close IMHO. > > > > For 2027, week 9 would be Mar/3 which seems to be too far out? > > > > > > > > Second release (week 25) for 2027 would be Jun/23, which would be > 4.6? > > > > > > > > So the question remains, where to put 4.5 so we can start to follow > the new schedule starting with 4.6. It seems KIP freeze between Jan 13 > might be a good compromise putting it roughly between 4.4 and 4.6 KIP > freeze dates. Of course, the release would overlap with Chinese New Year, > but it would be the last time we have this overlap. > > > > > > > > Just my 2tc. > > > > > > > > > > > > -Matthias > > > > > > > >> On 9/15/26 8:17 AM, David Jacot wrote: > > > >> Hi all, > > > >> Have we converged on the schedule that we want to use yet? Based on > > > >> the last emails, it is not so clear to me. For your context, I am > > > >> trying to figure out the timeline for 4.5. > > > >> Best, > > > >> David > > > >>> On Fri, May 29, 2026 at 1:03 PM Christo Lolov < > [email protected]> wrote: > > > >>> > > > >>> I think we could be a bit more lax with the KIP freeze of 6.7.0 > when > > > >>> 2034 comes around to account for LNY :) > > > >>> > > > >>> Joking aside, my preference between "KIP freeze would be > Wednesday's, > > > >>> weeks 9 / 25 / 41, with feature freeze +3 weeks, and code freeze +2 > > > >>> weeks" and "start Q1 release with X buffer after LYN and complete > Q3 > > > >>> release with Y buffer before Christmas" would be to start with the > > > >>> first and adjust by shifting by 1 week on individual basis the ones > > > >>> which are too close. I am okay with too close being defined as 2 > > > >>> weeks. Based on your very detailed tables we seem to have only a > few > > > >>> such outliers in the next decade. > > > >>> > > > >>> Best, > > > >>> Christo > > > >>> > > > >>> On Fri, 29 May 2026 at 08:35, Chia-Ping Tsai <[email protected]> > wrote: > > > >>>> > > > >>>> Matthias, you are definitely a master of scheduling! I'm +100 to > your plans. > > > >>>> > > > >>>> Also, it is absolutely helpful to write down the exact release > dates for the next few years at once. It will ease our anxiety a lot! I'd > be more than happy to update the wiki with these dates once we all agree on > this new schedule. For example: > > > >>>> > > > >>>> Version KIP Freeze Feature Freeze Code Freeze Target > Release > > > >>>> 4.4.0 Jun 17, 2026 Jul 8, 2026 Jul 22, 2026 Aug 19, > 2026 > > > >>>> 4.5.0 Oct 7, 2026 Oct 28, 2026 Nov 11, 2026 Dec 9, > 2026 > > > >>>> 4.6.0 Mar 3, 2027 Mar 24, 2027 Apr 7, 2027 May 5, > 2027 > > > >>>> 4.7.0 Jun 23, 2027 Jul 14, 2027 Jul 28, 2027 Aug 25, > 2027 > > > >>>> 4.8.0 Oct 13, 2027 Nov 3, 2027 Nov 17, 2027 Dec 15, > 2027 > > > >>>> 4.9.0 Mar 1, 2028 Mar 22, 2028 Apr 5, 2028 May 3, > 2028 > > > >>>> 5.0.0 Jun 21, 2028 Jul 12, 2028 Jul 26, 2028 Aug 23, > 2028 > > > >>>> 5.1.0 Oct 11, 2028 Nov 1, 2028 Nov 15, 2028 Dec 13, > 2028 > > > >>>> > > > >>>> Furthermore, let's do our best to avoid fixing release blockers > under the Christmas tree :) > > > >>>> > > > >>>> On 2026/05/28 21:22:51 "Matthias J. Sax" wrote: > > > >>>>> Thanks for the input. > > > >>>>> > > > >>>>> Overall, it seems that 3+2 weeks for feature freeze / code freeze > > > >>>>> windows gets a lot of support. > > > >>>>> > > > >>>>> However, the idea of dividing the release windows not into 3 > equally > > > >>>>> long junks, but be more flexible to account for holiday seasons, > seems > > > >>>>> not to get a lot of support? Not sure why... I personally think > it would > > > >>>>> be good to take it into account, and I also think that Chia-Ping > raises > > > >>>>> a very good point. > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> @Chia-Ping: Other holidays are a great point. Thanks for raising > it. I > > > >>>>> did actually briefly think about it, but it's difficult, and > thus I just > > > >>>>> started with something simple as proposal to kick off a > discussion. > > > >>>>> > > > >>>>> I think, Diwali is short enough to not make it a concern > (similar to > > > >>>>> Thanksgiving)? > > > >>>>> > > > >>>>> For Lunar New Year, I agree that it would be good to plan for it. > > > >>>>> However, it seems it's shifting quite a lot year-over-year what > makes it > > > >>>>> very difficult (w/o a huge window) to include? > > > >>>>> > > > >>>>> Overall, a 5 / 3.5 / 3.5 schedule seems to be quite unbalanced > (this > > > >>>>> would be 22 / 15 / 15 weeks per release? And two very short 3.5 > month > > > >>>>> releases does not sound very appealing? > > > >>>>> > > > >>>>> > > > >>>>> I was playing with it a little bit more. Overall we have 52 > weeks, so > > > >>>>> roughly 17.3 weeks per release. So we can naturally split it into > > > >>>>> 17/17/18 using the additional week for the holidays. But that's > not good > > > >>>>> enough to take both Christmas and Lunar New Year into account. > However, > > > >>>>> with a 16/16/20, we could make it work I believe, even if it > does cut it > > > >>>>> tight sometimes... To be able to phrase a "simple rule", we can > use ISO > > > >>>>> weeks: > > > >>>>> > > > >>>>> KIP freeze would be Wednesday's, weeks 9 / 25 / 41, with feature > freeze > > > >>>>> +3 weeks, and code freeze +2 weeks. > > > >>>>> > > > >>>>> Ie, we put the first KIP freeze after LNY with plenty of buffer > for most > > > >>>>> years: > > > >>>>> > > > >>>>>> > > ┌──────┬────────┬────────────────────────────┬───────────────────────────────────────┐ > > > >>>>>> │ Year │ LNY │ Q1 KIP freeze (week 9 Wed) │ > Buffer │ > > > >>>>>> > > ├──────┼────────┼────────────────────────────┼───────────────────────────────────────┤ > > > >>>>>> │ 2027 │ Feb 6 │ Mar 3 │ 25 days > │ > > > >>>>>> > > ├──────┼────────┼────────────────────────────┼───────────────────────────────────────┤ > > > >>>>>> │ 2028 │ Jan 26 │ Mar 1 │ 34 days > │ > > > >>>>>> > > ├──────┼────────┼────────────────────────────┼───────────────────────────────────────┤ > > > >>>>>> │ 2029 │ Feb 13 │ Feb 28 │ 15 days > │ > > > >>>>>> > > ├──────┼────────┼────────────────────────────┼───────────────────────────────────────┤ > > > >>>>>> │ 2030 │ Feb 3 │ Feb 27 │ 24 days > │ > > > >>>>>> > > ├──────┼────────┼────────────────────────────┼───────────────────────────────────────┤ > > > >>>>>> │ 2031 │ Jan 23 │ Feb 26 │ 34 days > │ > > > >>>>>> > > ├──────┼────────┼────────────────────────────┼───────────────────────────────────────┤ > > > >>>>>> │ 2032 │ Feb 11 │ Feb 25 │ 14 days > │ > > > >>>>>> > > ├──────┼────────┼────────────────────────────┼───────────────────────────────────────┤ > > > >>>>>> │ 2033 │ Jan 31 │ Mar 2 │ 30 days > │ > > > >>>>>> > > ├──────┼────────┼────────────────────────────┼───────────────────────────────────────┤ > > > >>>>>> │ 2034 │ Feb 19 │ Mar 1 │ 10 days ← > tightest with realistic LNY │ > > > >>>>>> > > ├──────┼────────┼────────────────────────────┼───────────────────────────────────────┤ > > > >>>>>> │ 2035 │ Feb 8 │ Feb 28 │ 20 days > │ > > > >>>>>> > > └──────┴────────┴────────────────────────────┴───────────────────────────────────────┘ > > > >>>>> > > > >>>>> Guess, we could also make it week-8 instead of 9, and accept > that 2034 > > > >>>>> would cut it too short (or be even more flexible and keep week-9 > for > > > >>>>> 2034 as an exception to the rule), but that's a single year... > for 2029 > > > >>>>> and 2032 we still have one week buffer. > > > >>>>> > > > >>>>> For Christmas, we would still ensure that the release can go out > on > > > >>>>> time, too. The below Q3 target release date is 4 weeks after code > > > >>>>> freeze. This is a little bit more tight, as we often need more > than 4 > > > >>>>> weeks to get it done: > > > >>>>> > > > >>>>>> ┌──────┬──────────────────────────┬────────────────┐ > > > >>>>>> │ Year │ Q3 release (week 50 Wed) │ Days to Dec 25 │ > > > >>>>>> ├──────┼──────────────────────────┼────────────────┤ > > > >>>>>> │ 2026 │ Dec 9 │ 16 │ > > > >>>>>> ├──────┼──────────────────────────┼────────────────┤ > > > >>>>>> │ 2027 │ Dec 15 │ 10 │ > > > >>>>>> ├──────┼──────────────────────────┼────────────────┤ > > > >>>>>> │ 2028 │ Dec 13 │ 12 │ > > > >>>>>> ├──────┼──────────────────────────┼────────────────┤ > > > >>>>>> │ 2029 │ Dec 12 │ 13 │ > > > >>>>>> ├──────┼──────────────────────────┼────────────────┤ > > > >>>>>> │ 2030 │ Dec 11 │ 14 │ > > > >>>>>> ├──────┼──────────────────────────┼────────────────┤ > > > >>>>>> │ 2031 │ Dec 10 │ 15 │ > > > >>>>>> ├──────┼──────────────────────────┼────────────────┤ > > > >>>>>> │ 2032 │ Dec 8 │ 17 │ > > > >>>>>> ├──────┼──────────────────────────┼────────────────┤ > > > >>>>>> │ 2033 │ Dec 14 │ 11 │ > > > >>>>>> ├──────┼──────────────────────────┼────────────────┤ > > > >>>>>> │ 2034 │ Dec 13 │ 12 │ > > > >>>>>> ├──────┼──────────────────────────┼────────────────┤ > > > >>>>>> │ 2035 │ Dec 12 │ 13 │ > > > >>>>>> └──────┴──────────────────────────┴────────────────┘ > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> For some years, we would still cut it a little bit tight, but we > could > > > >>>>> also apply an exception to the rule, to compensate for it. If we > have > > > >>>>> enough buffer room from LYN, we can start the Q1 release train a > week > > > >>>>> earlier, reducing the Q3->Q1 timeline by one week. > > > >>>>> > > > >>>>> > > > >>>>> Curious to hear what people think about it. In the end, if we > can agree > > > >>>>> on high level rules like "start Q1 release with X buffer after > LYN", and > > > >>>>> "complete Q3 release with Y buffer before Christmas", and still > aim for > > > >>>>> an as balance week-allocation per release, we can just put > together a > > > >>>>> release plan for the next 10 years and be done with it. > > > >>>>> > > > >>>>> > > > >>>>> -Matthias > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> On 5/28/26 3:51 AM, Christo Lolov wrote: > > > >>>>>> Hello, > > > >>>>>> > > > >>>>>> Thanks for pushing for this! I can confirm that the 4.2.0's > release > > > >>>>>> coincided with a reasonable amount of holidays, so I would > favour a > > > >>>>>> 3+2 schedule with releases in March, July and November. > > > >>>>>> > > > >>>>>> Best, > > > >>>>>> Christo > > > >>>>>> > > > >>>>>> On Thu, 28 May 2026 at 07:05, Ismael Juma <[email protected]> > wrote: > > > >>>>>>> > > > >>>>>>> Hi, > > > >>>>>>> > > > >>>>>>> On Wed, May 27, 2026 at 12:44 AM Andrew Schofield < > [email protected]> > > > >>>>>>> wrote: > > > >>>>>>> > > > >>>>>>>> I would go for 3 releases of equal lengths in March, July and > November. I > > > >>>>>>>> favour the 3+2 schedule. > > > >>>>>>>> > > > >>>>>>> > > > >>>>>>> +1 > > > >>>>>>> > > > >>>>>>> Thanks, > > > >>>>>>> Ismael > > > >>>>> > > > >>>>> > > > > > > > > > >
