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