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