Hey Zoltan It does seem nicer that the milestones are set as our development is done. Thanks for the initiative.
Regarding the RC, the end of week deadline SGTM. On Wed, Jan 21, 2026 at 7:43 PM Zoltan Haindrich <[email protected]> wrote: > Hey All, > > Yesterday I've tried to validate if all PRs which are with a 36.0.0 > milestone are present on the 36.0.0 branch. > Since some of those are already merged into master I had to also look at > closed PRs. > I want to change how these are being tracked a little bit as the above > process have some room for errors. > - PR opened > - someone sets milestone X > - the PR will show up as a requirement for that milestone > - PR merged > - the PR will disappear from the milestone as its closed > > I've put together a PR to make that unnecessary: after a PR is merged: > * assign the PR to the next release milestone based on the pom.xml > * if there is a different milestone on the PR create an issue about > backporting the PR for that milestone is created > > additionally if the approved label is added to the issue - a backport PR > is created - after merging that the issue should be closed. > > I plan to create an RC around the end of the week - does that sound good? > > cheers, > Zoltan > > On 1/15/26 9:35 AM, Zoltan Haindrich wrote: > > Hey, > > > > Of course - it seems to me that this docs PR might have just got stuck > or forgotten; which is quite unfortunate. > > Please add the release version 36.0.0 to PRs which should be in 36 or > discussed (mention me if you can't set the version..or it doesn't exists > yet) - so that we don't > > forget about them! > > > > cheers, > > Zoltan > > > > On 1/15/26 4:09 AM, Satya Anuroop Kuppam wrote: > >> +1 to projections documentation in 36. I think we should include the > >> documentation, so folks can start experimenting with the feature. > Currently > >> projections are called out in release notes but no documentation exists, > >> which is confusing. > >> > >> *Thanks. Regards* > >> *Satya* > >> > >> > >> On Tue, Jan 13, 2026 at 3:20 AM Frank Chen <[email protected]> > wrote: > >> > >>> I didn't receive the initial email from Zoltan about the 36 release > branch > >>> cutting. > >>> was it sent in the dev channel? > >>> > >>> One thing I just wanted to check is that the following document update > >>> about PROJECTION has NOT been merged yet, which was supposed to be > included > >>> in Druid 35. > >>> Will it be included in this release? > >>> > >>> https://github.com/apache/druid/pull/18056 > >>> > >>> > >>> > >>> > >>> On Tue, Jan 13, 2026 at 5:19 AM Abhishek Balaji Radhakrishnan < > >>> [email protected]> wrote: > >>> > >>>> 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] > >>>> > >>>> > >>> > >> > > > >
