What's difficult for me to grok here is you're treating each branch as static, while the discussion has already evolved to branches evolving over time (with jdks being back-ported, etc). Might be more helpful to explain states and events at different points of branch lifecycles…
On Tue, 3 Jun 2025 at 00:16, Josh McKenzie <jmcken...@apache.org> wrote: > I originally had "everyone supports highest language level whee" which of > course would fail to build on older branches. > > So this new paradigm would give us the following branch:language level > support (assuming JDK bump on each release which also won't always happen): > - trunk: latest > - trunk-1: latest lang - 1 > - trunk-2: latest lang - 2 > > So while trunk-1 and trunk-2 would both *support* the newest JDK > (wherever possible) for runtime, they wouldn't be switched to the new > language level. That'd leave us able to use the newest language features on > trunk much more rapidly while *effectively snapshotting the supported > language on older branches to the lowest JDK they support* (which, when > they're last in line and about to fall off, is the JDK that was newest at > the time they came about). > > Our risk would be patches going to trunk targeting new language features > we then found out we needed to back-port would require some massaging to be > compatible with older branches. I suspect that'll be a rare edge-case so > seems ok? > > Unless I'm completely missing something. I was the one who originally just > wanted to "latest JDK All The Things" for a hot minute there. =/ > > On Mon, Jun 2, 2025, at 9:40 AM, Doug Rohrer wrote: > > 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: > > 1. Running all CI across all supported JDK on a cadence > 2. 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 … :) > > > >
