One option is to just have a separate 4.0 branch for development to not block work on new features.
With Apache Accumulo <https://github.com/apache/accumulo> we have a similar situation where we have a separate branch (ironically also 4.0) that we are calling "elasticity" that is a long running branch with a ton of breaking changes. Our main branch line is still 3.1.x. Our workflow is that we just continuously merge main forward into elasticity to keep things up to date. When elasticity/4.0 is ready to be the next release we plan to merge it into main. So for Kafka, we could have a branch created that is for version 4.0.0 and people could do work only related to 4.x in that branch. For example, I'm going to open up a draft PR soon for KIP-1032 that only belongs there. Work that can go into 3.9.0 or 3.10.0 can stay in trunk and periodically trunk can be merged forward into the 4.0.0 branch. Once KIP-853 is ready we can merge 4.0.0 back into trunk. The downside is having to resolve merge conflicts that come up as things diverge but the upside is allowing work to keep moving. On Tue, Jul 30, 2024 at 1:27 PM Josep Prat <josep.p...@aiven.io.invalid> 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é > > > > >> > > > > > > > > > > > > > > > > > -- > [image: Aiven] <https://www.aiven.io> > > *Josep Prat* > Open Source Engineering Director, *Aiven* > josep.p...@aiven.io | +491715557497 > aiven.io <https://www.aiven.io> | <https://www.facebook.com/aivencloud > > > <https://www.linkedin.com/company/aiven/> < > https://twitter.com/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 >
