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
On Tue, 20 May 2025 at 11:36, 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? >> >>
