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 … :) >>>>>>> >>>>> >>> >
