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
