Page History

...

Sometimes there can be a need to deprecate a specific feature version (see Non-goals section). This requirement translates to increasing the cluster-wide finalized minimum version level of one or more features in the ZK '/features' node. Such feature version deprecations are typically announced in advance to the Kafka community. This is It is important to note that we only allow the finalized feature maximum version level to be increased/decreased dynamically via the new controller API. Contrastingly, the minimum version level can not be
mutated via the Controller API. This is because, the minimum version level is usually increased only to indicate the intent to stop support for a certain feature version. We would usually deprecate features during broker releases,
after prior announcements. Therefore, this is not a dynamic operation, therefore this mutation need not be and such a mutation is not supported through the Controller ApiKeys.UPDATE_FEATURES controller API. Instead, during a specific release of the Controller module, during the startup sequence the Controller logic would be arranged to mutate the ZK

Instead it is sufficient if such changes are done directly by the controller i.e. during a certain Kafka release we would change the controller code to mutate the '/features'

...

ZK node increasing the minimum version level

...

of one or more finalized features (this will be a planned change, as determined by Kafka developers). Then, as this Broker release gets rolled out to a cluster, the feature versions will become permanently deprecated.

Client discovery of finalized feature versions

...