Ok. Final Form before I take it to a VOTE: ----------------------------------------------- *[New LTS JDK Adoption]* • When a new JDK goes LTS, we prioritize: • Moving trunk to build, run, pass CI, and support language level of that JDK, dropping others • Adding support to *run* on that JDK to all supported GA releases, passing all CI using that JDK • These 2 operations must merge atomically. This allows us to preserve the contract of allowing like-to-like JDK's for a live C* upgrade *[Build, run, language level, Pre Commit CI, EOL]* • trunk builds, runs, has CI on, and supports the language level of 1 JDK at any given time (ideally latest LTS JDK) • Supported non-trunk GA branches: • build, run, pass CI, and support the language level of *the oldest JDK they are certified for* • Are supported to *run* on all LTS JDK's between their oldest supported and newest LTS supported by 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. The feature is flagged for deprecate-then-remove or re-implementation based on dev ML discussion. If removed, we drop the required older JDK across all branches when the feature is removed. Supporting new LTS JDK's is considered higher priority than supporting features that JDK's are no longer compatible with, pending debate on the dev ML. • Dropping JDK support happens naturally as old releases go EOL. *[Post Commit CI]* • Periodically we will run all CI pipelines for all *runtime* supported JDK's for that branch • We will add basic perf testing across all GA branches with reference workloads from easy-cass-stress for a simple performance-based smoke test
On Wed, Jun 11, 2025, at 4:53 PM, Josh McKenzie wrote: >> it might not always be smooth sailing – we might be losing some agility. >> But let's give it a go and find out. > Yeah, good point. When I bring it to VOTE I'll see if I can't massage the > wording a tiny bit around our intent to get to latest LTS support on trunk > but retain flexibility to wait if during a burn down to a release, if > problems are discovered, if certain things are deprecated and necessitate > change or waiting on lifecycle, etc. > > The directional statement of intent - we want to be on the latest JDK on > trunk when reasonable so the next release supports latest LTS - is where I > think the real value is. Leaves a lot of flexibility though on timing. > > > On Wed, Jun 11, 2025, at 4:09 PM, Mick Semb Wever wrote: >> You replied accurately to what i said, we're aligned. One point to continue >> is below… >> >> >>> >>>> And then, will the confidence of jdk12 in trunk be complete before its >>>> merge, and at what point can jdk11 safely be dropped ? >>>> >>>> The action of dropping jdk11 in trunk is just a one-liner in build.xml >>>> (actually code removal can happen later), but it's a commitment from us >>>> that jdk12 will be production ready. If attaining that confidence happens >>>> post-merge then there's a window where there is a chance we end up having >>>> to cut 2.0 with 11+12 ? >>> This is an interesting question. Do we have sufficient confidence that when >>> an OpenJDK LTS release hits it's stable? Assuming we can run our entire >>> suite of CI (and add in a future harry stress, a harry soak, and simulator >>> into the mix), what other bar for readiness do we have? >>> >> >> >> CI pre-commit doesn't catch everything. We can assume new LTS jdks come out >> reasonably safe now, but we've also seen the time it takes to stabilise >> something post-merge. Whether it's flakies, test variants that weren't run, >> especially if we start moving tests to only post-commit weekly runs, or just >> access to people available to be running harry. Or bugs reported by users >> running the new jdk on the older branches that come in late creating a hold >> up (and forcing a commitment: because there's no alternative jdk now; on) >> trunk. >> >> I don't have any objections here, just pointing out it might not always be >> smooth sailing – we might be losing some agility. But let's give it a go >> and find out. >
