DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
The proposal is to create 4 levels, 1 being the lowest and 4 being the most mature level. By having these levels, the release manager can easily know if KIPs are present in a release (and under which category) of if they need to be postponed to the next one. Only KIPs that are declared level 2 and onwards can be released in a given release, KIPs that remain in Level 1 are to be pushed to further releases.
During the discussion phase of a KIP, the community needs to agree if the KIP itself is complex enough in order for this graduation steps to apply.
Public Interfaces
No changes in public interfaces
...
A KIP in level 3 should be KIPfeature-complete (as per the KIP that defined it), it can still be evolved in terms of, for example, adding more and better metrics, documentation, or improving certain usability aspects of the KIP. The KIP is intended to work in different types of production environments, but there might be some aspects that might need some more testing and validation. The purpose of this level is to request help from the community to test this KIP under said scenarios to confirm the KIP works as expected. For example, help might be needed to test the KIP in extreme high volume environments.
...
This level is optional, and a KIP must not go through it in order to reach the latest level. Any KIP set at this level is encouraged to remain in it for 2 releases before graduating to level 4. This is just a recommendation.
Level 4
This is the final stage of the KIP. Any KIP might reach to this level directly, but it's only recommended for simpler and smaller KIPs.
...
The API for this KIP is to be considered stable and it can't change without undergoing a full deprecation cycle (at least 12 months in deprecated state after being removed in a "major" release). The KIP might be enabled by default (not all new functionalities need to be enabled by default)
Table
| Level | Completed? | API Stable? | Use in Production? | Must go through this level? | Enabled by Default? |
|---|---|---|---|---|---|
| 1 | No | No | No | Yes[1] | No |
| 2 | Partially | No | No | No | No, might experimental flag enabled |
| 3 | Yes | Yes | Maybe | No | No |
| 4 | Yes | Yes | Yes | Yes[2] | Maybe |
...
Each graduation step can be stated by the developer "owning" the KIP. The developer might decide to seek consensus via a VOTE thread to promote to level 3 and 4.
Currently, KIPs have a "Current state" field that contains the following values: "Under Discussion", "Voting", "Rejected" and "Accepted". This KIP proposes to update this field with the right graduation level once the KIP reaches it.
Definition of "Usable"
During this KIP "usable" is being used extensively in this proposal. Having a really prescriptive definition for "usable" might probably exclude certain types of KIPs to feel identified with this process. This is why we could understand "usable" in a similar way that "Minimum Viable Product" defines it:
Usable refers to a product or version that delivers enough functionality to allow users to achieve their primary goals.
In our scope, usable means that a KIP has enough parts implemented that the end users can start testing it and providing feedback even though the KIP might not be yet feature complete.
Compatibility, Deprecation, and Migration Plan
...
Using "alpha", "beta" and "gamma" has been rejected because of the widespread use and understanding of what "alpha" and "beta" mean in software developmentbeing used as a qualifiers for software versions not features within a software. For example the Wikipedia page: https://en.wikipedia.org/wiki/Software_release_life_cycle. Talking about alpha and beta might create confusions about users with regards of the stability of the Kafka version itself.