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 > > > > >>> > > > > >> > > > > > > > > > >
