Hi Greg,
Thanks for following up on this issue.
I'd be supportive of backporting this specific change to 3.9.
Thanks,
Mickael
On Tue, Dec 17, 2024 at 6:02 PM Greg Harris
wrote:
>
> Hey Luke and Divij,
>
> Updating our LTS policy, and/or declaring 3.9 an LTS version is a much
> larger topic than
Hey Luke and Divij,
Updating our LTS policy, and/or declaring 3.9 an LTS version is a much
larger topic than I intended to bring up here.
And I don't believe LTS is necessary or sufficient to perform this backport:
* 3.9 is currently supported: it's our latest release.
* Restrictions like the one
https://lists.apache.org/thread/tzx4zkhfz26joq5ydq70bxcfr3zwy1hk is a
discussion we had in the community a few years ago about the LTS / end of
life topic. Some of the conversation touched about a longer
maintenance window for last minor versions (and hence, treat it as LTS).
I think it is perhaps
Hi Greg,
Thanks for raising this.
My main question is: Is Kafka v3.9 a LTS release?
It seems many people think it is, but I never see this kind of discussion
anywhere.
In Kafka, IIRC, we have never had this kind of LTS release before.
We need to clearly define the meaning of LTS release for v3.9.x
Hi all,
Another downstream project has reported upgrade difficulties because of our
Java support policy:
https://github.com/quarkusio/quarkus/issues/39634
Thanks,
Greg
On Tue, Dec 3, 2024 at 7:33 AM Chia-Ping Tsai wrote:
> hi all,
>
> I believe this is an NP-hard challenge because we aim to re
hi all,
I believe this is an NP-hard challenge because we aim to release version 4.0 as
quickly, stably, and effectively as possible. In the meantime, the progress of
4.0 increases the gap between 4.0 and 3.9. This means that backporting fixes
and improvements to 3.9 will require additional res
Java 23 is not LTS (Long Term Support) by Oracle
Do we still want to proceed?
Thanks
Swikar
> On Dec 2, 2024, at 1:07 PM, Greg Harris wrote:
>
> Hi all,
>
> Thanks for the discussion so far, but I would like to refocus on the
> problem at hand.
>
> Our downstream users are asking for things
Hi all,
Thanks for the discussion so far, but I would like to refocus on the
problem at hand.
Our downstream users are asking for things that come at a cost to us as
maintainers: An exception to our processes, better support for the final
bridge release, and an easier maintenance burden.
What is
Hi Greg,
Comments below.
On Thu, Nov 21, 2024 at 8:07 AM Greg Harris
wrote:
> > Greg, why can't we set the relevant system property
> > automatically for the broker/connect in 3.9.x?
>
> The System property workaround is not effective for Java 24
This is a fair point. At the same time, where
Hi Ismael,
Thanks for your responses.
> At the same time, where do we draw the line when it
> comes to future unreleased Java versions?
I don't think we need to make a determination on that at this time. We are
making a one-time judgement about backporting a specific patch to a
specific branch.
Hi Ismael,
Thanks for your question
> Greg, why can't we set the relevant system property
> automatically for the broker/connect in 3.9.x?
The System property workaround is not effective for Java 24, and doesn't
cover the kafka-as-a-library use-case, which is the one which is generating
pain for
We had agreed to extend _critical bug fixes_ for one year for 3.9.
Something beyond that would require its own separate discuss thread, it
should not be in the middle of a thread about Java 23 support in 3.9. I am
personally not in favor of a LTS or 18-24 months cycle - it would divert a
lot of res
Hello,
I also think this sounds like a reasonable suggestion, also given that 3.9
was the first version to make KRaft feature complete, which means it's the
first version to bring production readiness for KRaft, in many contexts.
+1 from me.
BR,
Den tors 21 nov. 2024 kl 10:51 skrev Josep Prat :
Hi all,
Given 3.9 is the latest version before a major, and 4.0.0 comes with
breaking changes (Zookeeper removal, Scala and Java version drops...) I
think it's fair to assume that a considerable subset of Kafka users will be
using 3.9 for a little longer than we usually support versions (roughly 1
Dear all,
It seems the main question is whether we should consider version 3.9 as an
LTS release. For example, will we continue with versions like 3.9.1, 3.9.2,
... 3.9.100?
If yes, we should backport both KIP-1006 and support for future JDKs.
If not, backporting KIP-1006 to 3.9 would be suffici
> Has the SecurityManager been fully removed in JDK 23?
> What is the effect of running Kafka 3.9.0 with JDK 23?
The SecurityManager has been degraded, so by default our users experience
an UnsupportedOperationException. They can work-around this by setting a
system property.
In JRE 24, JEP-486 [1
Greg,
I have not been following this closely, so apologies for some basic
questions.
Has the SecurityManager been fully removed in JDK 23?
What is the effect of running Kafka 3.9.0 with JDK 23?
By "4.0 breaking changes" do you mean changes to our JDK/Scala supported
versions, removal or ZK, Kaf
We (Trino project) started testing JDK 24 compatibility recently and got
blocked for testing Kafka connector due to a Security Manager removal in
JDK 24 build 22 for which there is no workaround.
We'd love to continue supporting the Kafka connector, but forcing users to
upgrade to 4.0+ compatible
Hi all,
Now that 3.9.0 is released and 4.0.x is progressing, I'd like to understand
everyone's expectations about the 3.9.x branch, and ask for a specific
consensus on Java 23 support.
Some context that I think is relevant to the discussion:
* KIP-1006 [1] proposes a backwards-compatible strategy
19 matches
Mail list logo
