Kafka 4.4 waits on another release candidate as two operational KIPs take shape

Apache Kafka 4.4.0 entered September without a release vote after blocker defects were found in its first release candidate, while two new improvement proposals target day-to-day diagnosis and a long-standing replication-setting trap.

Kafka 4.4 remains in stabilization

Red Hat’s August Kafka community digest says the 4.4 branch was cut Aug. 11 and RC0 followed on Aug. 21, but three blocker issues were identified afterward. The digest expects another candidate in early September rather than treating RC0 as release-ready.

That timing is consistent with the upstream Kafka 4.4.0 release plan, which set code freeze for Aug. 12 and says the release should land no earlier than Sept. 9 after at least four weeks of stabilization. For users planning a 4.4 evaluation, the practical message is to test candidates, not to schedule production adoption against an assumed date.

Two proposals address operator friction

The digest highlights three KIPs filed in August, with two carrying direct operational consequences. KIP-1370, still under discussion, would add group instance IDs to regular kafka-streams-groups.sh --describe --members output and rack IDs to its verbose form. The data already exists in the Streams group description API; the proposal would expose it in the command-line view used to diagnose static membership and rack-aware placement. Scripts that parse fixed output columns would need adjustment if the change is accepted.

KIP-1372, also under discussion, would reject new topic configurations where min.insync.replicas exceeds the resolved replication factor. Kafka currently accepts that contradiction and clamps the effective minimum to the replication factor. The proposal would instead return INVALID_CONFIG at topic creation or a topic-level configuration change, while grandfathering existing topics and leaving cluster-level defaults unchanged. If adopted, workflows that increase durability would need to raise replication first and then raise the minimum in-sync replica count.

Strimzi 1.2 updates the Kubernetes side

The same digest also flags Strimzi Kafka Operator 1.2.0. Its release notes add Kafka 4.3.1 support, direct creation of connectors in paused or stopped states, and broker cordoning during scale-down rebalancing for Kafka 4.3 and later. The release also warns that only the v1 custom-resource API is supported in Strimzi 1.x, making CRD conversion an explicit pre-upgrade check for older installations.

None of the Kafka 4.4 or KIP work is final yet. The useful signal from August is narrower: the release remains in stabilization, and the proposals now under discussion are aimed at making configuration failures earlier and troubleshooting data easier to reach.