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: >> 1. Are bugfixes or non-invasive improvements we think are trunk only so >> leverage latest language level features, that >> 2. are non-trivial in size or scope, and >> 3. 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: >>>> 1. At any given time as a project we have a JDK version that shares >>>> support between 2 branches. >>>> 2. 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. >>>> 3. 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). >>>> 4. We are able to aggressively adopt new language level features for >>>> improvements and new features on trunk >>>> 5. Bugfixes that apply to older GA branches will need to target maximally >>>> the language level of the oldest branch to which they apply >>>> 6. 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? >>>>>>>> <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 … :) >>>>>>>> >>>>>> >>>> >> >
