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