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