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