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