To close the loop here, I've updated our "Patching, release versioning, and LTS releases <https://cwiki.apache.org/confluence/display/CASSANDRA/Patching%2C+release+versioning%2C+and+LTS+releases>" wiki article with the agreed upon text here. I added the following clarification from the consensus on the prior ML thread: > We strive for a "never deprecate or remove" approach. Any deprecation or > removal needs a dev ML [DISCUSS] thread with clear consensus.
Will see if I can't dig up the consensus on "never deprecate" and update the wiki w/that if it's clear, and hope to get a "how we do JDK support" [DISCUSS] thread going later this week. On Fri, Apr 25, 2025, at 5:03 PM, Jordan West wrote: > On Wed, Apr 23, 2025 at 21:04 Joseph Lynch <joe.e.ly...@gmail.com> wrote: >> Isn't the JDK we build with when publishing to maven somewhat of a public >> interface due to cassandra-all library usage? I agree that we probably just >> need to clearly document what JVMs we test a release on which is a good >> signal for what we think will work at runtime (and this may be a much newer >> JVM than we built with). >> > > For better or worse the community has largely treated cassandra-all use > (outside of official projects like cassandra-analytics) as “at your own > risk”. > >> >> Apologies I didn't intend to change what we were voting on, I was just >> trying to understand if we were voting on the original text or the original >> text *plus* the "we don't break things and discuss breakage before breaking >> apis" (which I still can't find on the wiki, but I am likely just bad at >> search). >> >> I do agree version and feature support is perhaps a separate topic from >> killing the minor (which seems unambiguously good). >> >> -Joey >> >> >> On Wed, Apr 23, 2025 at 7:47 PM Josh McKenzie <jmcken...@apache.org> wrote: >>> __ >>> Pragmatically, I believe our in-jvm upgrade dtests require the 2 versions >>> of C* you're testing to both support running on (and probably right now >>> building on) a shared JDK version. So for instance, if we had: >>> >>> - Release 21.0.0: JDK30, JDK31 >>> - Release 22.0.0: JDK35, JDK40 >>> >>> We wouldn't be able to test an upgrade from 21 to 22. Arguably we could >>> *build* on an older supported version and run both on the newer, but at >>> least right now I think that's our restriction. There's tension here if our >>> release cadence and LTS JDK's intersect badly, but JDK LTS is infrequent >>> enough relative to our releases that I think we're potentially getting >>> worked up about a non-issue here. >>> >>> Since the JDK isn't an API and we've already discussed and have some >>> measure of consensus in the past (I thought; haven't dug that up now due to >>> shortage of time), I think we can and should formalize that separately from >>> this vote thread. >>> >>> On Wed, Apr 23, 2025, at 6:31 PM, David Capwell wrote: >>>>> Also, I thought we had separate discussion about them - that we want to >>>>> keep up possibly with the last two LTS versions. >>>> >>>> This is what I remember as well. 6.0 would support 17/21 as thats the >>>> latest, if 7.0 is out before 25, then 7.0 would be 17/21, else it would be >>>> 21/25 >>>> >>>>> On Apr 23, 2025, at 3:11 PM, Ekaterina Dimitrova <e.dimitr...@gmail.com> >>>>> wrote: >>>>> >>>>> I should say that I also haven’t thought of JDK versions when I voted >>>>> here. Also, I thought we had separate discussion about them - that we >>>>> want to keep up possibly with the last two LTS versions. Currently we do >>>>> not have vision on when will be the next release date, so I cannot >>>>> personally align JDK LTS versions to our versioning. Also, depends on >>>>> people availability and testing resources when and what versions we will >>>>> maintain our builds with. (And when and what Cassandra releases we will >>>>> have, too) >>>>> >>>>> Regarding the - “do not change what we vote for in the middle of the >>>>> vote” - I agree, this is not the way to do it. But honestly I did not >>>>> perceive this voting as such a case. I also knew about the agreement that >>>>> any breaking changes will be discussed on the dev mailing list prior >>>>> removal and we try to be backward compatible as much as possible. >>>>> >>>>> On Wed, 23 Apr 2025 at 18:02, Jeremiah Jordan <jerem...@apache.org> wrote: >>>>>> > The JVM version also isn’t a feature to deprecate, technically. >>>>>> I agree with this. I think the JVM version the server runs under and how >>>>>> we cycle those is a separate discussion from feature deprecation. >>>>>> >>>>>> There can and has been some overlap there that would need to be handled >>>>>> on a case by case basis (when a new JVM removed something that we did >>>>>> not have a good way to keep doing without it, talking about you >>>>>> scripting runtime based UDFs), but in general I don’t think switching >>>>>> JVMs is the same as feature removal/deprecation. >>>>>> >>>>>> -Jeremiah >>>>>> >>>>>> >>>>>> On Wed, Apr 23, 2025 at 4:48 PM Jordan West <jw...@apache.org> wrote: >>>>>>> I agree with Jon that I’m now a bit confused on part of what I voted >>>>>>> for. It feels like there is more discussion to be had here. Or we need >>>>>>> to split it into two votes if we want to make progress on the part >>>>>>> where there is consensus and revisit where there is not. >>>>>>> >>>>>>> Regarding JVM version what I’ve mostly seen as reasons against forcing >>>>>>> a JVM upgrade with a C* upgrade is risk tolerance. Folks bit by past >>>>>>> upgrades have a tendency to want to limit as many variables as >>>>>>> possible. From a technical perspective I’m not sure that’s justified >>>>>>> tbh but having been one of the folks wanting to reduce variables and >>>>>>> still getting bit by upgrades I understand it. The JVM version also >>>>>>> isn’t a feature to deprecate, technically. And having made the decision >>>>>>> once to hold off on upgrading the JVM and regretting it I too would >>>>>>> like to see the project try to keep pace with JVM releases instead of >>>>>>> being on older LTS or unsupported versions. >>>>>>> >>>>>>> >>>>>>> Jordan >>>>>>> >>>>>>> On Wed, Apr 23, 2025 at 13:49 Jon Haddad <j...@rustyrazorblade.com> >>>>>>> wrote: >>>>>>>> > If 5.0 supports 17, then 7.0 should too, if we are to say we >>>>>>>> > support 5.0 to 7.0 upgrades. >>>>>>>> >>>>>>>> I have to disagree with this. I don't see a good reason have a tight >>>>>>>> coupling of JVM versions to C* versions, and I also don't see a good >>>>>>>> reason to overlap outside of CI. Even on CI, the reasoning is a bit >>>>>>>> weak, Linux distros have supported multiple JDK versions for at least >>>>>>>> a decade (update-java-alternatives on Ubuntu and alternatives on >>>>>>>> RedHat). >>>>>>>> >>>>>>>> I've heard several folks explain their reasoning for overlap in JVM >>>>>>>> versions, and it just doesn't resonate with me when weighed against >>>>>>>> the downsides of being anchored to the limitations imposed by >>>>>>>> supporting old JVM versions. >>>>>>>> >>>>>>>> I don't want this to come back and bite us later - so unless we're >>>>>>>> exempting the JVM version from this upgrade requirement, I'm changing >>>>>>>> my vote to -1. >>>>>>>> >>>>>>>> Furthermore, really shouldn't be changing the terms of the thing we're >>>>>>>> voting on mid-vote. This feels really weird to me. Anyone who cast a >>>>>>>> vote previously may not be keeping up with the ML on a daily basis and >>>>>>>> it's not fair to impose changes on them. People should be aware of >>>>>>>> what they're voting for and not be surprised when the VOTE is closed. >>>>>>>> >>>>>>>> Jon >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Apr 23, 2025 at 1:04 PM Mick Semb Wever <m...@apache.org> >>>>>>>> wrote: >>>>>>>>> . >>>>>>>>> >>>>>>>>>> This reads to me that Java 17 would need to be deprecated now, >>>>>>>>>> continue to be deprecated in 6.0 (at least one major in deprecated), >>>>>>>>>> then removed in 7.0. >>>>>>>>> >>>>>>>>> >>>>>>>>> This is technically true. But I don't think we need to be explicitly >>>>>>>>> deprecating jdk versions. Users are generally aware of Java's LTS >>>>>>>>> cycle, and we can document this separately. >>>>>>>>> >>>>>>>>> Where we are bound is that our upgrade tests require an overlapping >>>>>>>>> common jdk. So we can only test upgrades that support a common jdk. >>>>>>>>> And 🥁 IMHO, we should not be saying we recommend/support upgrades >>>>>>>>> that we don't test (regardless if not having broken compatibility >>>>>>>>> means we think untested upgrade paths would still work). If 5.0 >>>>>>>>> supports 17, then 7.0 should too, if we are to say we support 5.0 to >>>>>>>>> 7.0 upgrades. >>>>>>>>> >>>
