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,
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
Adding the user-mailing list. Seems relevant to everybody.
On 4/20/23 2:45 AM, Divij Vaidya wrote:
Thank you Matthias for your comments.
I agree with you that the decision should be driven based on strong
community ask as it introduces a significant overhead on the maintainers. I
was hoping
Thank you Matthias for your comments.
I agree with you that the decision should be driven based on strong
community ask as it introduces a significant overhead on the maintainers. I
was hoping that more folks (users of Kafka) would contribute to this thread
with their opinion but perhaps, I need
While I understand the desire, I tend to agree with Ismael.
In general, it's a significant amount of work not just to do the actual
releases, but also the cherry-pick bug-fixed to older branches. Code
diverges very quickly, and a clean cherry-pick is usually only possible
for one or two
Regarding#2 - About the support of minor versions:
Fair enough. We can keep the current policy for latest minor versions until
we can reduce the effort it requires to release a version.
Regarding#1 - About the last major version release:
About backporting security patches to the latest minor
Clarification below.
I did not understand your point about maintenance expense to ensure
> compatibility. I am confused because, IMO, irrespective of our bug fix
> support duration for minor versions, we should ensure that all prior minor
> versions are compatible. Hence, increasing the support
Thank you for your comments, Ismael.
1. About the last major version release: There is precedence in open
source projects such as Spark, Pulsar etc. that are already offering a
LTS/major version support with longer support duration than Kafka. If we
limit our support to include production
Hi,
I think we're discussing two separate things and each has a very different
cost and benefit:
1. Having a longer support period for the last minor release: major
releases happen pretty rarely and have breaking changes. It seems
reasonable to consider improving how this case is handled. And it
Hi folks
The goal of this discussion is to re-visit the End Of Life (EOL) policy of
Kafka and introduce a few changes to it.
*Current EOL policy*
Kafka currently follows a time based release plan with an EOL policy
documented here:
10 matches
Mail list logo
