On Tue, May 20, 2025 at 08:12 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 > > I agree having overlap is a good thing but we don’t need to be consecutive. Using this as an example, we could go [17,23] and skip 21 if 23 is already out and mature. > 1. > 1. We confirm C* builds on both supported JDK's > 2. We run all test suites against all supported JDK's for a release > (yet more incentive to clean up slow tests..) > 3. Language level support will be constrained to oldest JDK supported > 4. 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? > >
