This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.

Status

Current state: "Under Discussion"

...

The idea is to define a production-ready MetadataVersion defined in MetadataVersion.java as LATEST_PRODUCTION such that all MetadataVersions less than or equal to this value are stable and ready for production. By default only those features with a MV less than or equal to the LATEST_PRODUCTION MV will be available to use in a cluster. A cluster can set "unstable.metadata.versions.enable" to true in the broker and controller properties file to enable the use of a MV greater than LATEST_PRODUCTION in a cluster. Unit tests will default to use all MetadataVersions defined not just those less than or equal to LATEST_PRODUCTION so that developers can add unit tests for new features easily. Any unstable feature which requires a new MV can have that MV change in a later release of Apache Kafka as to a higher MV. This will occur when other features with a higher MV become stable and ready for production. A MV defined as unstable will never have its MV moved to a lower MV.

Public Interfaces

A new property "unstable.metadata.versions.enable" will be created to allow for developers to create clusters and use features with an unstable MV.

...

• Features with a stable MV will never have that MV change!
• Users will only be able to use features with a stable MV unless they explicitly configure their clusters with the new property.When will we remove the existing behavior?
• Features with an unstable MV may have that MV increased if a feature with a higher MV becomes stable and ready for production.

Test Plan

Describe in few sentences how the KIP will be tested. We are mostly interested in system tests (since unit-tests are specific to implementation details). How will we know that the implementation works as expected? How will we know nothing broke?

Rejected Alternatives

We will validate that the StorageTool will only format the metadata log to a stable MV unless "unstable.metadata.versions.enable" is set to true in the properties file.

We will validate that only stable features are enabled in the defaultFeatureMap unless the enableUnstable is set to trueIf there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.