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