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