Page History

...

Having a server-level configuration is problematic because individual brokers can be misconfigured, resulting in a cluster operating in a mixed state. Moreover, the current implementation shows transitional Additionally, there is inconsistent behavior across different coordinator types. While : while share groups have completely decoupled from group.coordinator.rebalance.protocols, the new group coordinator and streams still rely depend on this configuration. This means that even when the feature version is upgraded via via kafka-features.sh, the new capabilities remain unavailable unless the server configuration is also updated. This dual requirement exists because the feature flag mechanism was introduced later in the development cycle, resulting in a transitional period where both systems coexist. This can lead to user confusion when feature upgrades don't immediately enable new capabilities.

...

The group.coordinator.rebalance.protocols configuration will be deprecated in Kafka 4.x 3 and removed in version 5.0, following the same approach as Share Groups. The configuration will be decoupled from feature functionality, meaning it will be accepted but ignored during the transition period. Both New Group Coordinator and Streams will follow the Share Groups model where functionality is controlled solely by group.version  and streams.version  feature via kafka-features.sh. This eliminates the dual requirement of setting both configuration and feature flags, providing a consistent experience across all coordinator types. Users should use kafka-features.sh for all feature version management, and can safely remove the configuration from their server.properties files as it no longer affects feature functionality.

...