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