+1 to option 2 I guess the culprit of the delay is still the "must-have backports/CVEs" :)
On 2026/10/31 20:44:28 Andrew Schofield via dev wrote: > Hi Matthias, > Option 2 works for me and seems like a good way to transition to > the more regular release cadence in the future. > > Thanks, > Andrew > > On 2026/10/29 22:32:18 Matthias J. Sax wrote: > > Thanks Andrew. > > > > I see that you did keep Jan/13 for KIP freeze, and did not pull it > > forward. LGTM. > > > > > > > but I think it's very hard to be concrete about 4.6.0 at this point. > > > > Is it? In the end, if we say we want to follow the long-term proposed > > timeline in general, we are looking into the following dates: > > > > Proposed KIP-freeze dates for 2027 > > > > Release-1: March/3 (week 9) > > Relasee-2: June/23 (week 25) > > Release-3: Oct/13 (week 41) > > > > So there is two options: > > > > (1) We keep March/3, and do 4 release in 2027. Personally, I don't > > think this make a lot of sense. With the Jan/13 KIP freeze for AK 4.5 > > the cycle for AK 4.6 would be way too short IMHO. > > > > (2) We treat the AK 4.5 release as release-1, ie, pull forward the > > March/13 date to Jan/13, and follow with release-2 in June/23 as > > planned. -- Here we would still have some wiggle room: release-1 is 7 > > weeks earlier than the proposed schedule, so it would make sense to pull > > forward release-2, too. If we keep June/23 for release-2, we would have > > 23 weeks for AK 4.6 release, and only 16 weeks for release-3. It might > > be better to even it out and move release-2 forward by 3 week to have 20 > > weeks for AK 4.6, and 19 weeks for AK 4.7 with Oct/13 KIP freeze date as > > originally proposed. > > > > > > I would propose to go with option-2 and doing AK 4.6 with KIP freeze > > Jun/2 (ie, 3 weeks earlier than the proposed long-term schedule). > > > > > > -Matthias > > > > > > On 10/12/26 3:17 AM, Andrew Schofield wrote: > > > Hi, > > > I have gone ahead with the 4.5.0 schedule as listed, but I think it's very > > > hard to be concrete about 4.6.0 at this point. > > > > > > Thanks, > > > Andrew > > > > > > On 2026/10/10 20:33:35 Muralidhar Basani via dev wrote: > > >> Hi all, > > >> > > >> I'm not deeply involved in release management, so please take this as > > >> just > > >> some data in case it's useful for the 4.5/4.6 discussion. > > >> > > >> I compared the planned dates on the wiki release plans with what actually > > >> happened in git for the last five releases: > > >> > > >> Version Planned Feat Freeze Branch cut Planned target Released > > >> Late RCs > > >> 4.0.0 2024-12-11 2024-12-16 2025-01-29 > > >> 2025-03-18 48d 5 > > >> 4.1.0 2025-06-04 2025-06-10 2025-07-09 > > >> 2025-09-02 55d 4 > > >> 4.2.0 2025-11-19 2025-11-21 2026-01-07 > > >> 2026-02-16 40d 5 > > >> 4.3.0 2026-03-18 2026-03-18 2026-05-06 > > >> 2026-05-20 14d 3 > > >> 4.4.0 2026-07-29 2026-07-27 2026-09-09 > > >> 2026-10-12* 33d 5 > > >> (* expected) > > >> > > >> Feature freeze is usually on time; the time between code freeze and the > > >> release is where we tend to need more than planned (median ~40 days after > > >> the target). With the current 4.5.0 plan, that would put the 4.5.0 > > >> release > > >> around late April 2027, which may be worth keeping in mind when choosing > > >> the 4.6.0 dates. > > >> > > >> I put the small script in this PR, in case it's helpful for future > > >> planning: https://github.com/apache/kafka/pull/23769 > > >> Added sample runs in the PR. > > >> If this is not the direction we want, happy to close it. > > >> > > >> > > >> Here is a short snippet from the scripts run > > >> > > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >> > > >> % python3 release/schedule.py > > >> .... > > >> .... > > >> version KIP freeze derived from feature freeze code freeze > > >> first RC target release realistic release > > >> ------- ---------- ----------------- -------------- > > >> ----------- ---------- -------------- > > >> ----------------- > > >> 4.5.0 2027-01-13 wiki release plan 2027-02-03 2027-02-17 > > >> 2027-03-16 2027-03-17 2027-04-28 > > >> 4.6.0 2027-05-19 history 2027-06-09 > > >> 2027-06-23 > > >> 2027-07-20 2027-07-21 2027-09-01 > > >> 4.7.0 2027-09-22 history 2027-10-13 > > >> 2027-10-27 > > >> 2027-11-23 2027-11-24 2028-01-05 > > >> ... > > >> > > >> %python3 release/schedule.py --release-date 4.4.0=2026-10-12 status 4.6.0 > > >> .... > > >> .... > > >> Release 4.6.0 as of 2026-10-10 (dates: history) > > >> KIP freeze 2027-05-19 (in 221 days) > > >> feature freeze 2027-06-09 (in 242 days) > > >> code freeze 2027-06-23 (in 256 days) > > >> first RC 2027-07-20 (in 283 days) > > >> target release 2027-07-21 (in 284 days) > > >> realistic release 2027-09-01 (in 326 days) > > >> ... > > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >> > > >> > > >> Thanks, > > >> Murali > > >> > > >> On Sat, Oct 10, 2026 at 3:33 PM Matthias J. Sax <[email protected]> wrote: > > >> > > >>> What's you rational for doing 4.6 in March already? If we so 4.5 > > >>> early/mid January, it would be a very small release. Given the overhead > > >>> releases have, I am wondering if it would be worth doing? > > >>> > > >>> For 4.5, I am also ok to start a Jan/6 instead of Jan/13 with KIP > > >>> freeze. If we do 4.6 in July (instead of March) I don't see a need to > > >>> pull it forward by one a week though. But I am fine in any case. > > >>> > > >>> -Matthias > > >>> > > >>> On 9/28/26 11:49 PM, Dejan Stojadinović wrote: > > >>>>> "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 > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>> > > >>> > > >> > > > > >
