Hi Matthias, Note that is KIP-853 the one with the feature parity with ZK. KIP-1012 was the one were we agreed to stay on 3.x until feature parity. The reason to have a 3.10 is to have a safe way to upgrade to KRaft Kafkas while ZK is still around. We try to explain this in KIP-1012
------------------ Josep Prat Open Source Engineering Director, Aiven josep.p...@aiven.io | +491715557497 | aiven.io Aiven Deutschland GmbH Alexanderufer 3-7, 10117 Berlin Geschäftsführer: Oskari Saarenmaa, Hannu Valtonen, Anna Richardson, Kenneth Chen Amtsgericht Charlottenburg, HRB 209739 B On Tue, Jul 30, 2024, 22:10 Matthias J. Sax <mj...@apache.org> wrote: > Thanks for the input. However, I am wondering if releasing 3.9 makes > sense if KIP-1012 won't make it? > > My understanding was we do 3.9 only to not delay 3.8 and not delay 4.0. > > If we would go with a 3.10, would it also be an "intermediate" release > like 3.9? Or would it replace 4.0? For the first case, why not just > delay 3.9 until everything is ready? And for the latest case, why not > just do the 3.9 release in Nov and drop an intermediate release all > together? > > What do we gain by a 3.10 release? > > > -Matthias > > On 7/30/24 10:26 AM, Josep Prat wrote: > > +1 Greg. I'd be really happy to bump trunk to 4.0.0, but only once we > know > > we can safely do so. > > > > On Tue, Jul 30, 2024 at 7:24 PM Greg Harris <greg.har...@aiven.io.invalid > > > > wrote: > > > >> Hi all, > >> > >> I agree that we are not yet ready for breaking changes on trunk, so I > >> opened a PR to bump to 3.10.0-SNAPSHOT: > >> https://github.com/apache/kafka/pull/16732 > >> > >> When KIP-853 is feature complete, we can bump to 4.0.0-SNAPSHOT. > >> > >> Thanks, > >> Greg > >> > >> On Tue, Jul 30, 2024 at 10:01 AM Josep Prat <josep.p...@aiven.io.invalid > > > >> wrote: > >> > >>> Hi all, > >>> As per KIP-1012[1] we can't yet say if the next release will be 3.10.0 > or > >>> 4.0.0. It will come down to the state of KIP-853 in 3.9.0. > >>> > >>> So, in my opinion we should still wait before committing breaking > changes > >>> on trunk until we know for sure that KIP-853 will make it. > >>> Maybe Jose can share more about the chances of this. > >>> > >>> [1] > >>> > >>> > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1012%3A+The+need+for+a+Kafka+3.8.x+release > >>> > >>> Best > >>> > >>> > >>> ------------------ > >>> Josep Prat > >>> Open Source Engineering Director, Aiven > >>> josep.p...@aiven.io | +491715557497 | aiven.io > >>> Aiven Deutschland GmbH > >>> Alexanderufer 3-7, 10117 Berlin > >>> Geschäftsführer: Oskari Saarenmaa, Hannu Valtonen, > >>> Anna Richardson, Kenneth Chen > >>> Amtsgericht Charlottenburg, HRB 209739 B > >>> > >>> On Tue, Jul 30, 2024, 18:52 Matthias J. Sax <mj...@apache.org> wrote: > >>> > >>>> Thanks for cutting the release branch. > >>>> > >>>> It's great to see `trunk` being bumped to 4.0-SNAPSHOT, and I wanted > to > >>>> follow up on this: > >>>> > >>>> We have a bunch of tickets that we can only ship with 4.0 release, and > >>>> these tickets were blocked so far. I wanted to get confirmation that > we > >>>> will stick with 4.0 coming after 3.9, and that we can start to work on > >>>> these tickets? Or is there any reason why we should still hold off to > >>>> pick them up? We don't want to delay them unnecessary to make sure we > >>>> can them all into 4.0 release, but of course also don't want to work > on > >>>> them prematurely (to avoid that we have to revert them after merging). > >>>> > >>>> > >>>> -Matthias > >>>> > >>>> On 7/30/24 9:07 AM, Chia-Ping Tsai wrote: > >>>>> hi Colin, > >>>>> > >>>>> Could you please consider adding > >>>>> https://issues.apache.org/jira/browse/KAFKA-16666 to 3.9.0 > >>>>> > >>>>> The issue is used to deprecate the formatters in core module. Also, > >> it > >>>>> implements the replacements for them. > >>>>> > >>>>> In order to follow the deprecation rules, it would be nice to have > >>>>> KAFKA-16666 in 3.9.0 > >>>>> > >>>>> If you agree to have them in 3.9.0, I will cherry-pick them into > >> 3.9.0 > >>>> when > >>>>> they get merged to trunk. > >>>>> > >>>>> Best, > >>>>> Chia-Ping > >>>>> > >>>>> > >>>>> José Armando García Sancio <jsan...@confluent.io.invalid> 於 > >> 2024年7月30日 > >>>> 週二 > >>>>> 下午11:59寫道： > >>>>> > >>>>>> Thanks Colin. > >>>>>> > >>>>>> For KIP-853 (KRaft Controller Membership Changes), we still have the > >>>>>> following features that are in progress. > >>>>>> > >>>>>> 1. UpdateVoter RPC and request handling > >>>>>> <https://issues.apache.org/jira/browse/KAFKA-16533> > >>>>>> 2. Storage tool changes for KIP-853 > >>>>>> <https://issues.apache.org/jira/browse/KAFKA-16518> > >>>>>> 3. kafka-metadata-quorum describe changes for KIP-853 > >>>>>> <https://issues.apache.org/jira/browse/KAFKA-16521> > >>>>>> 4. kafka-metadata-quorum add voter and remove voter changes > >>>>>> <https://issues.apache.org/jira/browse/KAFKA-16523> > >>>>>> 5. Sending UpdateVoter request and response handling > >>>>>> <https://issues.apache.org/jira/browse/KAFKA-16534> > >>>>>> > >>>>>> Can we cherry pick them to the release branch 3.9.0 when they get > >>>> merged to > >>>>>> trunk? They have a small impact as they shouldn't affect the rest of > >>>> Kafka > >>>>>> and only affect the kraft controller membership change feature. I > >>>> expected > >>>>>> them to get merged to the trunk branch in the coming days. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> On Mon, Jul 29, 2024 at 7:02 PM Colin McCabe <cmcc...@apache.org> > >>>> wrote: > >>>>>> > >>>>>>> Hi Kafka developers and friends, > >>>>>>> > >>>>>>> As promised, we now have a release branch for the upcoming 3.9.0 > >>>> release. > >>>>>>> Trunk has been bumped to 4.0.0-SNAPSHOT. > >>>>>>> > >>>>>>> I'll be going over the JIRAs to move every non-blocker from this > >>>> release > >>>>>> to > >>>>>>> the next release. > >>>>>>> > >>>>>>> From this point, most changes should go to trunk. > >>>>>>> *Blockers (existing and new that we discover while testing the > >>> release) > >>>>>>> will be double-committed. *Please discuss with your reviewer > >> whether > >>>> your > >>>>>>> PR should go to trunk or to trunk+release so they can merge > >>>> accordingly. > >>>>>>> > >>>>>>> *Please help us test the release! * > >>>>>>> > >>>>>>> best, > >>>>>>> Colin > >>>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> -José > >>>>>> > >>>>> > >>>> > >>> > >> > > > > >
