Re: [DISCUSS] How we handle JDK support

[Josh McKenzie]

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  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  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 d

Re: [DISCUSS] How we handle JDK support

[Štefan Miklošovič]

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  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  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
> (wher

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

[Blake Eggleston]

> Adds overhead in the hot path due to maintaining indexes. Extra memory needed 
> during write path and compaction.

I’d make the same argument about the overhead of maintaining the index that Jon 
just made about the disk space required. The relatively predictable overhead of 
maintaining the index as part of the write and compaction paths is a pro, not a 
con. Although you’re not always paying the cost of building a merkle tree with 
snapshot repair, it can impact the hot path and you do have to plan for it.

> Verifies index content, not actual data—may miss low-probability errors like 
> bit flips

Presumably this could be handled by the views performing repair against each 
other? You could also periodically rebuild the index or perform checksums 
against the sstable content.

> Extra data scan during inconsistency detection
> Index: Since the data covered by certain indexes is not guaranteed to be 
> fully contained within a single node as the topology changes, some data scans 
> may be wasted.
> Snapshots: No extra data scan

This isn’t really the whole story. The amount of wasted scans on index repairs 
is negligible. If a difference is detected with snapshot repairs though, you 
have to read the entire partition from both the view and base table to 
calculate what needs to be fixed.

On Tue, Jun 3, 2025, at 10:27 AM, Jon Haddad wrote:
> One practical aspect that isn't immediately obvious is the disk space 
> consideration for snapshots.
> 
> When you have a table with a mixed workload using LCS or UCS with scaling 
> parameters like L10 and initiate a repair, the disk usage will increase as 
> long as the snapshot persists and the table continues to receive writes. This 
> aspect is understood and factored into the design.
> 
> However, a more nuanced point is the necessity to maintain sufficient disk 
> headroom specifically for running repairs. This echoes the challenge with 
> STCS compaction, where enough space must be available to accommodate the 
> largest SSTables, even when they are not being actively compacted.
> 
> For example, if a repair involves rewriting 100GB of SSTable data, you'll 
> consistently need to reserve 100GB of free space to facilitate this.
> 
> Therefore, while the snapshot-based approach leads to variable disk space 
> utilization, operators must provision storage as if the maximum potential 
> space will be used at all times to ensure repairs can be executed.
> 
> This introduces a rate of churn dynamic, where the write throughput dictates 
> the required extra disk space, rather than the existing on-disk data volume.
> 
> If 50% of your SSTables are rewritten during a snapshot, you would need 50% 
> free disk space. Depending on the workload, the snapshot method could consume 
> significantly more disk space than an index-based approach. Conversely, for 
> relatively static workloads, the index method might require more space. It's 
> not as straightforward as stating "No extra disk space needed".
> 
> Jon
> 
> On Mon, Jun 2, 2025 at 2:49 PM Runtian Liu  wrote:
>> > Regarding your comparison between approaches, I think you also need to 
>> > take into account the other dimensions that have been brought up in this 
>> > thread. Things like minimum repair times and vulnerability to outages and 
>> > topology changes are the first that come to mind.
>> 
>> Sure, I added a few more points.
>> 
>> *Perspective*
>> 
>> *Index-Based Solution*
>> 
>> *Snapshot-Based Solution*
>> 
>> 1. Hot path overhead
>> 
>> Adds overhead in the hot path due to maintaining indexes. Extra memory 
>> needed during write path and compaction.
>> 
>> No impact on the hot path
>> 
>> 2. Extra disk usage when repair is not running
>> 
>> Requires additional disk space to store persistent indexes
>> 
>> No extra disk space needed
>> 
>> 3. Extra disk usage during repair
>> 
>> Minimal or no additional disk usage
>> 
>> Requires additional disk space for snapshots
>> 
>> 4. Fine-grained repair  to deal with emergency situations / topology changes
>> 
>> Supports fine-grained repairs by targeting specific index ranges. This 
>> allows repair to be retried on smaller data sets, enabling incremental 
>> progress when repairing the entire table. This is especially helpful when 
>> there are down nodes or topology changes during repair, which are common in 
>> day-to-day operations.
>> 
>> Coordination across all nodes is required over a long period of time. For 
>> each round of repair, if all replica nodes are down or if there is a 
>> topology change, the data ranges that were not covered will need to be 
>> repaired in the next round.
>> 
>> 
>> 5. Validating data used in reads directly
>> 
>> Verifies index content, not actual data—may miss low-probability errors like 
>> bit flips
>> 
>> Verifies actual data content, providing stronger correctness guarantees
>> 
>> 6. Extra data scan during inconsistency detection
>> 
>> Since the data covered by certain indexes is not guaranteed to be fully 
>>

Re: [DISCUSS] How we handle JDK support

[Josh McKenzie]

> 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  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 t

Request for Wiki access to create CEP

[Kokoori, Shylaja]

Hi,
I would like to submit a CEP and I don't have access to the wiki.
If someone with access could provide permission to wiki ID 'shylaja', would be 
much appreciated.

Thank you,
Shylaja Kokoori

Re: Request for Wiki access to create CEP

[Brandon Williams]

Your account should have access now.

Kind Regards,
Brandon

On Tue, Jun 3, 2025 at 4:20 PM Kokoori, Shylaja
 wrote:
>
> Hi,
>
> I would like to submit a CEP and I don't have access to the wiki.
>
> If someone with access could provide permission to wiki ID 'shylaja', would 
> be much appreciated.
>
>
>
> Thank you,
>
> Shylaja Kokoori

Re: Accepting AI generated contributions

[scott]

So the general concern we're talking about is identifying/avoiding cases in 
which a community member has contributed code generated with the support of a 
model that has reproduced training data verbatim, posing copyright risk to the 
Apache Cassandra project.

Work in this area seems early, but there are a couple examples we should know 
about. Copilot and Amazon Q seem to have the most advanced capability here 
unless I've missed others.

– Copilot offers a feature called Code Referencing, which provides inline 
feedback indicating that generated source may match publicly-available source 
code; the source license; and source references: 
https://github.blog/news-insights/product-news/code-referencing-now-generally-available-in-github-copilot-and-with-microsoft-azure-ai/

– Amazon Q / CodeWhisperer implement a similar feature called Reference 
Tracker. This helps detect whether a suggestion is similar to 
publicly-available code, along with a repo link and license information: 
https://www.infoworld.com/article/2337694/amazon-q-developer-review-code-completions-code-chat-and-aws-skills.html

I'm not aware of specific functionality in models from OpenAI or Anthropic, 
though the Claude system prompt apparently directs the model not to reproduce 
copyrighted material in runs greater than 15 words. It’s not clear that there’s 
a model feature that explicitly guarantees this, though: 
https://simonwillison.net/2025/May/25/claude-4-system-prompt/#seriously-don-t-regurgitate-copyrighted-content

A spectrum of approaches we could consider to manage the project’s exposure to 
this risk:

(1) Requiring contributors using generative models to disclose that an 
assistive model was used, and what steps were taken to mitigate the risk of 
inclusion of copyrighted output. This could include requiring disclosure of 
models used and whether features like code referencing / reference tracking 
were applied to identify material similar to known OSS code.

(2) Requiring contributors using generative models to adopt features that 
proactively attempt to identify similarities to publicly-available source code 
as part of their development workflow and warrant that either no instances of 
code referencing were reported; or that any generated suggestions were subject 
to transformation significant enough that they constitute a transformative work.

(3) Implementing proactive scanning similar to approaches used in education 
like “TurnItIn,” which are deeply disliked by honest and dishonest students 
alike and policing this; or

(4) Disallowing contribution of source code developed with the support of 
generative models as a matter of policy.

Speaking for myself, I’d support an approach that:

(a) Requires disclosure of source code generated with the support of a coding 
LLM including which model and version.

(b) Requires contributors to enumerate steps taken to minimize the risk of 
inclusion of copyrighted content - e.g., use of features similar to the ones 
above; specificity of the work to the Cassandra codebase; or generality of the 
code generated (boilerplate).

(c) Requires contributors using assistive LLMs to warrant that they are the 
primary author of the patch - primarily to distinguish between use of language 
models as “enhanced IntelliSense” vs. unconscious vibe coding.

Note that the above a/b/c items are specific to the copyright concern and don’t 
approach other questions, such as whether we should be using generative tooling 
to develop a database used industry-wide as a system of record, or what burden 
this places on reviewers.

My own bread is buttered on the side of “I can’t be bothered to read something 
that someone didn’t bother to write.” But my hope is that any use of LLM-based 
tooling is sufficiently transformative as to become the original work of the 
contributor.

In the spirit of disclosure, every word above was written by me. I used Kagi 
and ChatGPT-4 turbo (free) very lightly as search aids to look up 
vendor-specific implementations of the code referencing and reference tracking 
features because I wasn’t aware of the name of the relevant product category.

– Scott

> On Jun 2, 2025, at 4:54 PM, Jeremiah Jordan  wrote:
> 
> I don’t think I said we should abdicate responsibility?  I said the key point 
> is that contributors, and more importantly reviewers and committers 
> understand the ASF guidelines and hold all code to those standards. Any 
> suspect code should be blocked during review. As Roman says in your quote, 
> this isn’t about AI, it’s about copyright. If someone submits copyrighted 
> code to the project, whether an AI generated it or they just grabbed it from 
> a Google search, it’s on the project to try not to accept it.
> I don’t think anyone is going to be able to maintain and enforce a list of 
> acceptable tools for contributors to the project to stick to. We can’t know 
> what someone did on their laptop, all we can do is evaluate the code they 
> submit.
> 
> -Jere

Re: [DISCUSS] How we handle JDK support

[Mick Semb Wever]

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