Only thing I’d suggest changing here is “Trunk targets the language level of that JDK” shouldn’t happen until after we’ve confirmed the back port of the new JDK LTS changes to previous versions - otherwise, you have folks starting to use new language features and then have to rip them all out when you find that some previous supported Cassandra release can’t use that JDK.
Doug > On May 27, 2025, at 10:37 AM, Josh McKenzie <jmcken...@apache.org> wrote: > > revised snapshot of the state of conversation here: > > [New LTS JDK Adoption] > Trunk supports 1 JDK at a time > After a branch is cut for a release, we push to get trunk to support latest > LTS JDK version available at that time > Trunk targets the language level of that JDK > CI on trunk is that single JDK only > We merge new JDK LTS support to all supported branches at the same time as > trunk > In the very rare case a feature would have to be removed due to JDK change > (think UDF's scripting engine), we instead keep the maximum allowable JDK for > that feature supported on trunk and subsequent releases. We then drop that > JDK across all branches once the oldest C* w/that feature ages out of support. > Otherwise, we don't need to worry about dropping JDK support as that will > happen naturally w/the dropping of support for a branch. Branches will slowly > gain JDK support w/each subsequent trunk-based LTS integration. > [Branch JDK Support] > N-2: JDK, JDK-1, JDK-2 > N-1: JDK, JDK-1 > N: JDK > [CI, JDK's, Upgrades] > CI: > For each branch we run per-commit CI for the latest JDK they support > TODO: Periodically we run all CI pipelines for older JDK's per-branch > (cadence TBD) > TODO: We add basic perf testing across all GA branches with reference > workloads (easy-cass-stress workloads? > <https://github.com/apache/cassandra-easy-stress/tree/main/src/main/kotlin/com/rustyrazorblade/easycassstress/workloads>) > Upgrades > N-2 -> N-1: tested on JDK and JDK-1 > N-2 -> N: tested on JDK > N-1 -> N: tested on JDK > > ----------------------- > The above has 2 non-trivial CI orchestration investments: > Running all CI across all supported JDK on a cadence > Adding some basic perf smoke tests > Both seem reasonable to me. > > On Fri, May 23, 2025, at 7:39 AM, Mick Semb Wever wrote: >> >> . >> >> >> For the rare edge case where we have to stop supporting something entirely >> because it's incompatible with a JDK release (has this happened more than >> the 1 time?) - I think a reasonable fallback is to just not backport new JDK >> support and consider carrying forward the older JDK support until the >> release w/the feature in it is EoL'ed. That'd allow us to continue to run >> in-jvm upgrade dtests between the versions on the older JDK. >> >> >> >> This. >> I think the idea of adding new major JDKs to release branches for a number >> of reasons, in theory at least. … >> >> >> I *like* the idea … :) >
