Hi Matthias, You're absolutely right! Sorry for the confusion. I actually used the usual message that we send out in all the releases. I will improve it in the release document for the next time.
David On Wed, Dec 18, 2024 at 8:58 AM David Jacot <dja...@confluent.io> wrote: > Hi Chia-Ping, > > Yes, we are going to move the "AsyncConsumer" to production ready in > 4.0.0. Therefore, we must continue to address the blockers for it. > > David > > On Wed, Dec 18, 2024 at 8:06 AM Matthias J. Sax <mj...@apache.org> wrote: > >> David, >> >> thanks for cutting the release branch. I think your email implies too >> strong of a restriction? (Or at least, it could easily be interpreted as >> such?) >> >> Yes, we should not cherry-pick any feature work into `4.0`, however, we >> are not at _code freeze_ yet, and thus regular bug-fixes _should_ >> actually still be cherry-picked to `4.0` from my understanding. >> >> Other examples are PRs which remove deprecated APIs for 4.0. >> >> My understanding is, that only after code freeze, we would only >> cherry-pick blockers. >> >> Maybe you did not mean it in a strong sense, but it easily read in such >> a strong interpretation, so I just wanted to clarify. >> >> >> -Matthias >> >> On 12/16/24 9:13 PM, Chia-Ping Tsai wrote: >> > hi David >> > >> > Are we planning to move AsyncConsumer to production in version 4.0.0? >> If not, can we assume that AsyncConsumer-related issues will be deferred to >> next release ? For example: >> https://issues.apache.org/jira/browse/KAFKA-18034 >> > >> > Best, >> > Chia-Ping >> > >> > On 2024/12/16 15:47:47 David Jacot wrote: >> >> Hello Kafka developers and friends, >> >> >> >> As promised, we now have a release branch for 4.0 release. >> >> Trunk has been bumped to 4.1.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! >> >> >> >> Thanks! >> >> >> >> Best, >> >> David >> >> >> >>
