...
We need to agree on the number of steps and what each of these steps mean for developers as well as for end users of said features. We had some discussion in the mailing list and gathered some feedback here: https://lists.apache.org/thread/5z6rxvs9m0bro5ssmtg8qcgdk40882bz
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.
Public Interfaces
No changes in public interfaces
...
[2]: As a final state of graduation all features aspire to get to this level.
Examples
After KIP-853: KRaft Controller Membership Changes got approved, it would have been positioned at Level 1. It stayed in that level for a while. In between, Kafka 3.8 release happened and it remained at Level 2. After that, it got promoted to Level 2 just in time to be taken in Kafka 3.9 release.
KIP-848: The Next Generation of the Consumer Rebalance Protocol on the other hand reached Level 2 at the time of Kafka 3.7. Improvements were done after that and when it was time to release Kafka 3.8 the KIP got promoted to Level 3.
An example of a feature in Level 4 could be KIP-390: Support Compression Level that reached this level during Kafka 3.8, and jumped directly from Level 1 to Level 4.
Names
- "In Development"
- "Early Access"
- "Preview"
- "Production Ready"
...