Page History

...

1. The usual regular usage of the API is a feature upgrade. This is by specifying a higher new max feature version level value (i.e. X' > X).

2. By default, the API disallows max feature version level downgrades (X' < X) and finalized feature deletions (X' < 1). Such changes are allowed to be attempted only if the allowDowngrade flag is specified. Note that despite this allowDowngrade flag being set, certain downgrades may be rejected by the controller if it is deemed impossible.

3. If any broker does not contain a required feature, this is considered an incompatibility → such a case will fail the API request.

4. If any broker contains an additional feature that’s not required → this is not considered an incompatibility.

5. Some/all of the above logic will also be used by the broker (not just the controller) for it’s protections (see this section of this KIP).

6. Activating the effects of a feature version cluster-wide is left to the discretion of the logic implementing the feature (ex: can be done via dynamic broker config).

7. Deprecating/eliminating the presence/effects of a specific feature version cluster-wide is left to the discretion of the logic backing the feature (ex: can be done via dynamic broker config). However, it may need further external verification to ensure no entity (ex: a consumer, or a broker) is actively using the feature (see Non-goals section).

...