Status

Current state: "Under DiscussionAdopted"

Discussion thread: here

JIRA: None (don't think this needs a Jira ticket)

...

During the "Road to Kafka 4.0" discussion in the mailing list (https://lists.apache.org/thread/mxltb2k5y17q89vg0k9492dfc8z66jw1), it became apparent that there are some features that are not yet present in KRaft that the community is relying on to successfully operate and run Kafka. Thus, making it either hard or not feasible for a subset of the community to move to KRaft (or at least fully test KRaft) before Zookeeper's complete removal in 4.0.0. Some community members might only be able to try KRaft when Zookeeper is gone, leaving only a downgrade as a way out path if something doesn't work as expected (instead of config switching)

This KIP proposes the creation of a to create at least one more minor version within the 3.x series ,3.8.0 release, and the scope of this KIP is to define which are the respective KIPs (mostly around KRaft KIPs ) that should be part of it so the community can safely embrace KRaft. migrate to a potential 4.0 version.

This way community members can safely test KRaft without the need to perform downgrades or manual workarounds, as ZooKeeper is meant to be removed in 4.0.

Public Interfaces

No direct interfaces will be changed by this KIP

...

• Have a release 3.8.x after 3.7.0
  • The aim of this release would be KRaft strategic feature parity with Zookeeper
• Once 3.8.0 is releasedbranched, immediately start with the 4.0.x release
• 3.8.x would be the last minor release within the 3.x series.

This assumes all must have features / KIPs are implemented in 3.8. Otherwise we would need to inject a 3.9 version in between 3.8 and 4.0

Scope

The following KIPs were identified by the community as blockers items that prevent them from migrating Kafka to KRaft.List of KIPs that are deemed "must have"'s in the scope of KRaft for 3.8.0:would need to be present in a 3.x release before moving to a potential 4.0 release.

We would aim to have all these in a 3.8 release. However, in the case that this is not possible and some of these blockers are still not resolved, we should then create a new minor version on the 3.x series (namely 3.9).

The following list is not an exhaustive list of new features 3.8 would contain (this release will most probably contain other features and KIPs).

Timeline

Release 3.7.0: TBD, probably early January 2024

...

Release 4.0.0: 3 to 4 months after 3.8 branch is created

This assumes all must have features / KIPs are implemented in 3.8. Otherwise we would need to inject a 3.9 version in between 3.8 and 4.0

Compatibility, Deprecation, and Migration Plan

...