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