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 and get the consensus from the community.
And once we all agree v3.9.x is a LTS release, I will be +1 for backporting the patch to support jdk 23. Otherwise, if we only have v3.9.1 release and no more maintenance for v3.9.x, why should we accept this "medium risk" decision? Thanks. Luke On Tue, Dec 17, 2024 at 1:06 AM Greg Harris <greg.har...@aiven.io.invalid> wrote: > 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 <chia7...@apache.org> wrote: > > > 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 > resources > > from the community. > > > > However, I can imagine that many Kafka users and customers will remain on > > version 3.x for a while. Therefore, it is worthwhile to keep releasing > > 3.9.x for bug fixes. For improvements or new features, we should keep > them > > in 4.x to encourage users to advance alongside the community. > > > > Best, > > Chia-Ping > > > > On 2024/12/02 21:42:23 Swikar Patel wrote: > > > 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 <greg.har...@aiven.io.invalid > > > > 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 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 our consensus here? Should we disregard our users, and > > prioritize > > > > ourselves first? > > > > > > > > Thanks, > > > > Greg > > > > > > > > > > > > > > > >> On Thu, Nov 21, 2024 at 12:52 PM Greg Harris <greg.har...@aiven.io> > > wrote: > > > >> > > > >> 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. We should have that discussion as a follow-up. > > > >> > > > >>> Is there evidence of this pain? That would help motivate the case. > > > >> > > > >> A downstream user has already replied to this thread, I'll relink it > > here > > > >> [1] and the issue they were working on [2]. > > > >> > > > >>> I don't think this is how we evaluate risk/reward, so I disagree > with > > > >> your > > > >>> position here. > > > >>> Requiring users to set a system property is far from "harming" > them. > > > >>> Nonetheless, if we can reduce friction, it's a good thing, > > > >> > > > >> I think you missed the point of my statement, which was that we > can't > > > >> justify our behavior by hiding among other libraries. > > > >> If everyone did that, nobody would ever respond to deprecations. > This > > is > > > >> an antisocial justification, I don't find it convincing, and we > > should not > > > >> rely on it. > > > >> > > > >> Thanks, > > > >> Greg > > > >> > > > >> [1] > https://lists.apache.org/thread/312lm617q05k87kxsrwlqhk8rfg29t7g > > > >> [2] https://github.com/trinodb/trino/issues/23498 > > > >> > > > >>> On Thu, Nov 21, 2024 at 12:16 PM Ismael Juma <m...@ismaeljuma.com> > > wrote: > > > >>> > > > >>> Hi Greg, > > > >>> > > > >>> Comments below. > > > >>> > > > >>> On Thu, Nov 21, 2024 at 8:07 AM Greg Harris > > <greg.har...@aiven.io.invalid > > > >>>> > > > >>> 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 do we draw the line > > when it > > > >>> comes to future unreleased Java versions? There are two possible > > paths: > > > >>> (1) > > > >>> we focus on the released versions, (2) we have a clear policy for > > future > > > >>> versions (the upcoming version, the upcoming LTS version, etc.). > > > >>> > > > >>> > > > >>>> and doesn't > > > >>>> cover the kafka-as-a-library use-case, which is the one which is > > > >>> generating > > > >>>> pain for our users. > > > >>>> > > > >>> > > > >>> Is there evidence of this pain? That would help motivate the case. > > > >>> > > > >>> > > > >>>> We already have a patch reviewed and merged which can fix this > > generally > > > >>>> (23/24, clients/streams/brokers/connect), and is low risk. Please > > review > > > >>>> the PR to convince yourself of this. > > > >>>> > > > >>> > > > >>> I did take a look at the PR and it did not seem low risk to me > (it's > > > >>> larger > > > >>> than we'd typically consider for bug fix releases, it includes > > reflection, > > > >>> etc.). And hence why I was exploring other options. But it's not > > > >>> necessarily high risk either, it's somewhere in between. > > > >>> > > > >>>> When it comes to usage of > > > >>>>> Kafka as a library (eg clients), I very much doubt kafka will be > > the > > > >>> only > > > >>>>> system that requires this system property to be set, so not sure > > how > > > >>> much > > > >>>>> it matters. > > > >>>> > > > >>>> I don't think other libraries' support for SecurityManager is > > relevant > > > >>> to > > > >>>> this discussion, as there almost certainly is a downstream project > > out > > > >>>> there for which Kafka is the only dependency blocking their > upgrade. > > > >>>> > > > >>> > > > >>> I don't think this is how we evaluate risk/reward, so I disagree > > with your > > > >>> position here. > > > >>> > > > >>> > > > >>>> And if all libraries took that strategy, that would harm the > > adoption of > > > >>>> Java 23 and users, so we should avoid implementing that strategy > > > >>> ourselves. > > > >>> > > > >>> > > > >>> Requiring users to set a system property is far from "harming" > them. > > > >>> Nonetheless, if we can reduce friction, it's a good thing, > > > >>> > > > >>> Ismael > > > >>> > > > >> > > > > > >
