Ultimately, maintaining both the ZK-based controller and the KRaft-based controller takes a substantial resource toll on the community. That's the reason why we agreed to drop the ZK based controller in Apache Kafka 4.0, as part of KIP-833.
If there is a serious bug in the last bridge release, we could certainly consider fixing it even if the EOL period is past for that release. But I think that's pretty unlikely and we can discuss it if and when it comes up. We've done everything we can to ensure compatibility with existing users, even to the point of re-adding the same bugs that ZK mode had in some cases. We've also put in a lot of work to ensure that migration will not involve any downtime. If there is something broken then let's fix the broken thing and move forward, just as we've always done. And just as Kafka system administrators have always done. best, Colin On Tue, May 16, 2023, at 09:29, Igor Soarez wrote: > My impression is also that a lot of users run older, > out of EOL, versions of Kafka. > > The final 3.x version is particularly concerning, as it will be > the last bridge to migrate away from ZK. If a big portion of users > only upgrade after its EOL period, we might only then discover an > important bug and potentially be cutting off the migration path (or > just making it really difficult) for a lot of users. > > Could the release efforts be re-shuffled perhaps to allow a longer > bug fix policy for the last minor release in each release version? > Or does the KRaft migration perhaps merit an exceptional case? > > -- > Igor
