Hi Zoltan, Yes, I’m all for regular quarterly releases like we’ve been doing. I was just specifically calling out the code freeze timelines and it would be helpful to have an overall tentative schedule laid out so folks know what to expect and when.
>> I'm happy to leave the branch open for a week - just don't want to block the >> master branch for new features which are ok to have in the next release. > Does that sounds good? This sounds good to me. Thanks, Abhishek On 2026/01/12 09:10:47 Zoltan Haindrich wrote: > Hey Abhishek, > > I think you are right the first email should have been sent out earlier - but > the regular schedule is more-or less to have a release in every quarter. > I'm a big believer in that the stream of regular releases are more important > than having everything in them - if there would be just a single release in > 1-2 years the push > to have a long code-freeze during which even features would be landed would > be bigger...but with every quarter: if you miss this you could just have it > in the next release. > > > I do think that cutting the branch is just a step which enables to finalize > the release branch - the release will only get more serious when the RC > builds is created. > > I'm happy to leave the branch open for a week - just don't want to block the > master branch for new features which are ok to have in the next release. > Does that sounds good? > > cheers, > Zoltan > > > On 1/10/26 4:43 AM, Abhishek Balaji Radhakrishnan wrote: > > Hi Zoltan, > > > > Thank you for volunteering to be the release manager for 36.0.0! > > > > In my opinion, a one-day notice is too short for a code freeze. A week’s > > heads-up would be really helpful so community developers can plan changes, > > get in-flight reviews expedited and prioritized accordingly. I’m not sure > > if there’s a process we have for the project, but I’m happy to start a > > separate discussion if that would be useful for future releases. > > > > I see that the 36.0.0 branch has already been cut. What do you think about > > having a “soft” code freeze for a week where contributors are still able to > > backport changes, after which we only backport release blockers, security > > and other critical bug fixes? > > > > I personally had plans to get some changes going, but I'm prioritizing > > reviews for https://github.com/apache/druid/pull/18731 if we can get that > > into 36.0.0, assuming the patch is ready to be merged by then. > > > > Thanks, > > Abhishek > > > > > > > > On 2026/01/09 16:50:55 Zoltan Haindrich wrote: > >> Hey All, > >> > >> I've branched off [36.0.0](https://github.com/apache/druid/tree/36.0.0) at > >> 7fc05156ab1165563455a617a0cc87990f2ad783 patch (current HEAD) > >> The vuln scan found that xz should be above 1.10.2 - have some license > >> issues in the [PR](https://github.com/apache/druid/pull/18898) it looks > >> like we won't get huge issues > >> from this direction. > >> The version update PR for the master branch [is > >> here](https://github.com/apache/druid/pull/18899) > >> > >> cheers, > >> Zoltan > >> > >> > >> On 1/7/26 5:59 PM, Zoltan Haindrich wrote: > >>> Hello all, > >>> > >>> To keep the regular pace of Druid releases; 36.0.0 should be rolled out > >>> in the upcoming month or so. > >>> I would like to volunteer to be the release manager for this one. > >>> Every earlier releases was started around the first few weeks of the > >>> quarter... :) > >>> It would be nice to open the branch this week. > >>> > >>> There are some interesting issues/PRs marked in the milestone [1]. > >>> * HttpRemoteTaskRunner enhancements #18851 [2] > >>> * seems like a a valuable PR - maybe the winter break have made it > >>> lag behind a bit... > >>> * its not a correctness issue - so I don't think it could be a blocker > >>> * Realtime scans from MSQ cannot reliably read complex types #18340 [5] > >>> * not sure if this could be a blocker - as earlier versions were also > >>> affected by this limitation. > >>> * Segment Load/Drop Race Causes Silent Partial Query Results #18738 [3] > >>> * has a lot of related discussions and some PRs > >>> * "Change segment state on HttpLoadQueuePeon ..." [4] seems to be > >>> fixing some part of the issue - but its not yet finished > >>> * I believe these race conditions were hiding in quite a few earlier > >>> versions without being uncovered - I would like to rely on Kashif / > >>> @jtuglu1 to decide if this > >>> should block the release or not. > >>> > >>> If there is anything more which should be discussed please reply to this > >>> thread and/or mark it on github with the 36.0.0 milestone [1] so that it > >>> doesn't fall off the radar! > >>> > >>> cheers, > >>> Zoltan > >>> > >>> [1] https://github.com/apache/druid/milestone/65 > >>> [2] https://github.com/apache/druid/pull/18851 > >>> [3] https://github.com/apache/druid/issues/18738 > >>> [4] https://github.com/apache/druid/pull/18824 > >>> [5] https://github.com/apache/druid/issues/18340 > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
