While I understand *some* users care, we shouldn't take the preferences of a very small minority of users as project policy. I've worked with hundreds of teams, and I can't recall a single one caring about doing A/B testing in JVM versions.
> There is also that recommendation that I keep on hearing - don’t do C* major upgrade and JDK upgrade simultaneously. I believe that was one of the reasons for overlap too There's no practical reason for this today. Maybe in the Java 6 or 8 days, sure. But now, it's a useless requirement. Jon On Tue, May 20, 2025 at 8:45 AM Benedict <bened...@apache.org> wrote: > In-jvm dtests need to execute an upgrade path on a single jvm, but this is > close to always possible on the latest jvm. We haven’t hit any issues that > I know of in this respect during any version change, so I don’t think this > is a real concern. > > Some users do care about overlapping JVM compatibility. Containers may be > exceptionally common but it is far from 100% coverage, and some operators > (myself included) prefer to decouple the effects of two different version > upgrades so as to decipher what change causes what effect. > > This gets stated on perhaps an annual basis, so perhaps we should start > having these conversations on wiki to avoid the repetition. > > > > On 20 May 2025, at 16:37, Jon Haddad <j...@rustyrazorblade.com> wrote: > > > There’s no “leaving users in the lurch” by requiring JDK upgrades. > > If users are using containers (pretty much everyone i talk to) then the > JDK is included, versions don’t matter. > > If not, every modern Linux distro supports multiple installed JDKS. Again, > not a problem. > > So far the only convincing argument I’ve heard is that we need overlapping > versions because of in-JVM dtests. Which is a shame, but sounds unavoidable > without a massive change that I’m sure nobody is interested in. > > Let’s not pretend like we’re doing this for the users though, they aren’t > getting any benefit from it. > > Jon > > > On Tue, May 20, 2025 at 8:12 AM Josh McKenzie <jmcken...@apache.org> > wrote: > >> This came up in the release versioning thread and we punted to its own >> thread. >> >> *Topic: How do we want to handle JDK version support in C* releases?* >> >> Oracle LTS policy here: >> https://www.oracle.com/java/technologies/java-se-support-roadmap.html >> >> My first rough thoughts: >> >> 1. Any given C* release will only support 2 JDK / JRE at any given >> time >> 2. We only change JDK support on MAJOR releases (i.e. not patch) >> 3. When we add support for a new JDK, we drop support for the older >> in that release >> 1. Every consecutive release *must share support for a runtime JDK >> version with one version older* (this allows for live upgrades, >> CI, etc). So if we take a long time releasing C* and multiple JDK's >> rev, we >> don't jump from [11,17] supported to [21,23] and leave users in a >> lurch on >> the straddle >> 4. We confirm C* builds on both supported JDK's >> 5. We run all test suites against all supported JDK's for a release >> (yet more incentive to clean up slow tests..) >> 6. Language level support will be constrained to oldest JDK supported >> 7. We make an effort to support the latest LTS JDK on any given C* >> release (i.e. 21 now, 25 next major when it goes LTS Sep of this year) >> >> The major downside I can think of with the above is operators will need >> to verify a new JDK maximally once every 2-3 years as older LTS support is >> dropped. >> >> What am I not thinking of? What are other downsides with the above >> proposal? >> >>
