Hi Chia-Ping Tsai, If you can get them done this week then I think we can merge them in to 3.9. If not, then let's wait until 4.0, please.
best, Colin On Tue, Jul 30, 2024, at 09:07, 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é >>
