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