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