Hi Matthias, Thanks for the feedback! I've adopted your suggestion and updated the KIP to include the broker-side validation and warning you proposed. This will inform users that the config will be removed in 5.0 and they won't be able to disable protocols via this configuration. Share groups indeed decoupled from this configuration a while ago (I submitted a minor PR to remove it from the valid values in doc), and their KIP explicitly states that version switching is done via kafka-features.sh, independent of this configuration.
Ming-Yen Matthias J. Sax <[email protected]> 於 2025年11月12日 週三 上午5:53寫道： > Thanks for the KIP. It's overall straight forward and make a lot of > sense to me. > > I just have one minor question: with the deprecation, should we add > broker code to verify that the value is "classic,consumer,streams" if > the config is set, and log a warning if one of the three protocolz is > missing (my understanding is that "share" is not used, but QfK did move > off this config earlier already), to tell users that this config will be > removed and they cannot disable a protocol with it in the future. > > > -Matthias > > On 11/10/25 7:02 PM, Ming-Yen Chung wrote: > > Hi all, > > > > I would like to start a discussion on > > KIP-1237: Deprecate group.coordinator.rebalance.protocols config > > <https://cwiki.apache.org/confluence/x/jIqmFw> > > > > Currently, Share Group has deprecated the > > group.coordinator.rebalance.protocols configuration, and it no longer > > affects feature functionality. Maybe we can adopt the same approach for > the > > New Group Coordinator and Streams rebalance protocol: deprecate this > > configuration and decouple it from feature functionality, allowing > features > > to be controlled solely via kafka-features.sh. The configuration would > then > > be completely removed in version 5.0. > > > > Does this approach make sense for the Group Coordinator and Streams? > Happy > > to hear any thoughts or concerns. > > > > > > Best, > > Ming-Yen > > > >
