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
> > >>>>> 
> > >>>>> 
> > > 
> > 
> 

Reply via email to