This makes sense to me. The release scripts confirm the JDK being used now, and this was the impetus to add that.
Kind Regards, Brandon On Tue, Jun 10, 2025 at 8:09 AM Josh McKenzie <jmcken...@apache.org> wrote: > > Was drafting up a VOTE thread and have one thing I want to add - anyone think > of any major issues w/this I'm missing? > > • All supported branches are built on the oldest JDK they support. Our > support model is: build on single JDK, run on oldest up to current LTS > > On Sat, Jun 7, 2025, at 10:53 AM, Josh McKenzie wrote: > > Any other thoughts on this? We think we're ready for a [VOTE] thread? > > On Tue, Jun 3, 2025, at 2:07 PM, Josh McKenzie wrote: > > 1) As you said, in trunk, we would go with the latest language level features > and if we backported and these language features are not present there > because of older JDK, the patch would need to be rewritten to comply. > > We already have plenty of cases where we have to write a patch for one > branch, merge -s ours, then --amend in a different patch for the subsequent > branch. I would expect this process (late-discovered multi-branch applying > patches) would be lighter weight than that and far less frequent. > > My intuition is that the number of patches that: > > Are bugfixes or non-invasive improvements we think are trunk only so leverage > latest language level features, that > are non-trivial in size or scope, and > we later determine we need to backport to older branches > > Is probably going to be vanishingly small. In most cases when working on a > bug or improvement it's pretty clear where it needs to land day 1. > > > On Tue, Jun 3, 2025, at 11:36 AM, Štefan Miklošovič wrote: > > Hi Josh, > > One observation, you wrote: > > "Backports from trunk to older branches that utilize the latest language > level would need to be refactored to work on older branches." > > This is interesting. There are two possibilities > > 1) As you said, in trunk, we would go with the latest language level features > and if we backported and these language features are not present there > because of older JDK, the patch would need to be rewritten to comply. > > 2) The patch would be written in such a way in trunk that it would use > language features which would be present in older branches already so a > backport would be easier in this regard as the code as such would not need to > be reworked if it does not differ functionally a lot otherwise. > > It seems to me you have already identified what might happen in your older > emails here: > > "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?" > > Totally agree. > > I do not know what approach I would use by default but thinking about it more > I would probably do 2) just for the sake of not rewriting it in older > branches. A patch might be complicated already enough and keeping in mind to > use newest features in trunk and not using them in older branches is just too > much of a mental jugglery to handle for me. > > I guess that the discussion when the usage of newest language features would > be recommended and justified would follow. I do not think that blindly using > the latest greatest _everywhere_ is always good when maintainers need to take > care of it for years in the light of backports and bug fixes etc. > > It probably also depends on how complex the patch is and if using the newest > language level would yield some considerable performance gains etc. > > Regards > > On Tue, Jun 3, 2025 at 4:38 PM Josh McKenzie <jmcken...@apache.org> wrote: > > > I was attempting to convey the language level support for a given branch at > any snapshot in time; my reading of Doug's email was for something that > shouldn't be a problem with this new paradigm (since we would be doing > bugfixes targeting oldest then merge up, and new improvements and features > should be going trunk only). > > Flowing through time, here's what a new release looks like at time of > release. I'll format it as: > C* Version / JDK Build Version / JDK Run Version(s) / Language Level > > For our first release: > > C* 1.0 / 11 / 11 / 11 > > Then we release the next C* version; for sake of illustration let's assume a > new JDK LTS 12: > > C* 2.0 / 12 / 12 / 12 > C* 1.0 / 11 / 11+12 / 11 > > Notice: we added the ability to run C* 1.0 on JDK12 and otherwise didn't > modify the properties of the branch re: JDK's. > > Then our 3rd release of C*, same assumption w/JDK LTS 13 support added: > > C* 3.0 / 13 / 13 / 13 > C* 2.0 / 12 / 12+13 / 12 > C* 1.0 / 11 / 11+12+13 / 11 > > The ability to run on the new JDK13 is backported to all supported branches. > Otherwise: no JDK-related changes. > > And upon our 4th release, we drop support for C*1.0: > > C* 4.0 / 14 / 14 / 14 > C* 3.0 / 13 / 13+14 / 13 > C* 2.0 / 12 / 12+13+14 / 12 > > The properties this gives us: > > At any given time as a project we have a JDK version that shares support > between 2 branches. > Any supported version of C* has a JDK that it can be run on that allows > upgrade to any other supported version of C* on that same JDK. > Operators retain the ability to verify a new JDK independently of the new C* > version (i.e. bump C* 2.0 from JDK12 to JDK13, then move from C* 2.0 on JDK13 > to C* 3.0 on JDK13). > We are able to aggressively adopt new language level features for > improvements and new features on trunk > Bugfixes that apply to older GA branches will need to target maximally the > language level of the oldest branch to which they apply > Backports from trunk to older branches that utilize the latest language level > would need to be refactored to work on older branches > > Does this exercise help clarify? > > On Tue, Jun 3, 2025, at 8:22 AM, Mick Semb Wever wrote: > > 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?) > > 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 … :) > > > > > > >
