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 <greg.har...@aiven.io.invalid> wrote: > > 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 > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > > > > > > >
