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 ones that Divij mentions would exclude this backport. This thread is discussing a specific patch and a specific version, not asking for us to make a judgment on patches unseen, which appears unpopular. > 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? Being compatible with Java 23+ on 3.9.x would allow downstream projects depending on clients to use Java 23 while still remaining compatible with all previous broker versions. It would allow them to postpone the breaking changes present in the 4.0 release until their own major release if desired. Even if 3.9.2 is never released, 3.9.1 will still provide value to the community. Thanks, Greg On Tue, Dec 17, 2024 at 12:25 AM Divij Vaidya <divijvaidy...@gmail.com> wrote: > 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 time to restart that conversation in the community. I > do see a benefit in having a LTS for 3.9.x with some constraints such as > only data durability and security patches are fixed etc. but I also > understand the operational cost it comes with. It's a healthy debate to > have with a wider section of folks (perhaps include users@ list and have a > new subject line for the discussion). > > Greg, would you be willing to kick-off that discussion? We can park this > thread until we conclude on the end of life story for 3.9.x. > > -- > Divij Vaidya > > > > On Tue, Dec 17, 2024 at 4:11 AM Luke Chen <show...@gmail.com> wrote: > > > 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 > > > > > >>> > > > > > >> > > > > > > > > > > > > > > >
