Re: [UPDATE] CEP-37

[Paulo Motta]

The long awaited feature of managed repairs is finally happening, this is
awesome! :)

Congrats all for this achievement!

On Wed, Apr 23, 2025 at 4:27 PM Jordan West  wrote:

> Great work all! Another awesome milestone and huge step forward for the
> project!
>
> On Wed, Apr 23, 2025 at 12:47 Jaydeep Chovatia 
> wrote:
>
>> The CEP-37 work has been successfully merged into the trunk today! Please
>> let me know if you have any issues.
>>
>> This merge is a massive win for Apache Cassandra — a significant step
>> forward. But we're not stopping here. There's more to come, and we are
>> committed to pushing repair automation even further and closing the gaps in
>> the remaining flows. A few examples:
>>
>>1. Automatically running repair as part of the node replacement:
>>Design
>>
>> 
>>& POC  is
>>already out [CASSANDRA-20281
>>]
>>2. Stopping repair automatically between Cassandra major version
>>upgrades [CASSANDRA-20048
>>]
>>3. Repairing automatically when Keyspace replication changes [
>>CASSANDRA-20582
>>]
>>
>> Thanks for all the help and support from the Apache Cassandra community!
>>
>> Yours sincerely,
>> Andy Tolbert, Chris Lohfink, Francisco Guerrero, Kristijonas Zalys, and
>> Jaydeep
>>
>> On Sun, Mar 9, 2025 at 8:53 PM Jaydeep Chovatia <
>> chovatia.jayd...@gmail.com> wrote:
>>
>>> Thanks a lot, Jon!
>>> This has truly been a team effort, with Andy Tolbert, Chris Lohfink,
>>> Francisco Guerrero, and Kristijonas Zalys all contributing over the past
>>> year. The credit belongs to everyone!
>>>
>>> Jaydeep
>>>
>>>
>>>
>>>
>>>
>>> On Sun, Mar 9, 2025 at 2:35 PM Jon Haddad 
>>> wrote:
>>>
 This is all really exciting.  Getting a built in, orchestrated repair
 is a massive achievement.  Thank you for your work on this, it's incredibly
 valuable to the community!!

 Jon

 On Sun, Mar 9, 2025 at 2:25 PM Jaydeep Chovatia <
 chovatia.jayd...@gmail.com> wrote:

> No problem, Dave! Thank you.
>
> Jaydeep
>
> On Sun, Mar 9, 2025 at 10:46 AM Dave Herrington 
> wrote:
>
>> Jaydeep,
>>
>> Thank you for taking time to answer my questions and for the links to
>> the design and overview docs, which are excellent and answer all of my
>> remaining questions.  Sorry I missed those links in the CEP page.
>>
>> Great work and I will continue to follow your progress on this
>> powerful new feature.
>>
>> Thanks!
>> -Dave
>>
>> On Sat, Mar 8, 2025 at 9:36 AM Jaydeep Chovatia <
>> chovatia.jayd...@gmail.com> wrote:
>>
>>> Hi David,
>>>
>>> Thanks for the kind words!
>>>
>>> >Is there a goal in this CEP to make automated repair work during
>>> rolling upgrades, when multiple versions exist in the cluster?
>>> We debated a lot on this over ASF Slack
>>> (#cassandra-repair-scheduling-cep37). The summary is that, ideally, we 
>>> want
>>> to have a repair function during the mixed version, but the reality is 
>>> that
>>> currently, there is no test suite available inside Apache Cassandra to
>>> verify the streaming behavior during the mixed version, so the 
>>> confidence
>>> is low.
>>> We agreed on the following: 1) Keeping safety in mind, we should by
>>> default disable the repair during mixed version 2) Add a comprehensive 
>>> test
>>> suite 3) Allow repair during mixed version. Currently, we are at #1
>>>
>>> >Would automated repair be smart enough to automatically stop, if it
>>> sees incompatible versions?
>>> That's the plan, and we already have PR (CASSANDRA-20048
>>> ) out from
>>> Chris Lohfink. The thing we are debating is whether to stop only during
>>> major version mismatch or also during the minor version, and we are 
>>> leaning
>>> towards only disabling for the major version mismatch. Regardless, this
>>> should be available soon.
>>> We are also extending this further as per feedback from David
>>> Capwell that we should automatically stop repair if we detect a new DC 
>>> or
>>> keyspace RF is changed. That will be covered later as part of
>>> CASSANDRA-20414
>>> 
>>>
>>> >If automated repair must be disabled for the entire cluster, will
>>> this be a single nodetool command, or must automated repair be disabled 
>>> on
>>> each node individually?
>>> Yes, it is a nodetool command and does not require any restarts! All
>>> the *nodetool* command det

Re: [VOTE] Simplifying our release versioning process

[Jon Haddad]

>   If 5.0 supports 17, then 7.0 should too, if we are to say we support
5.0 to 7.0 upgrades.

I have to disagree with this.  I don't see a good reason have a tight
coupling of JVM versions to C* versions, and I also don't see a good reason
to overlap outside of CI.  Even on CI, the reasoning is a bit weak, Linux
distros have supported multiple JDK versions for at least a decade
(update-java-alternatives on Ubuntu and alternatives on RedHat).

I've heard several folks explain their reasoning for overlap in JVM
versions, and it just doesn't resonate with me when weighed against the
downsides of being anchored to the limitations imposed by supporting old
JVM versions.

I don't want this to come back and bite us later - so unless we're
exempting the JVM version from this upgrade requirement, I'm changing my
vote to  -1.

Furthermore, really shouldn't be changing the terms of the thing we're
voting on mid-vote.  This feels really weird to me.  Anyone who cast a vote
previously may not be keeping up with the ML on a daily basis and it's not
fair to impose changes on them.  People should be aware of what they're
voting for and not be surprised when the VOTE is closed.

Jon



On Wed, Apr 23, 2025 at 1:04 PM Mick Semb Wever  wrote:

>.
>
>>
>> This reads to me that Java 17 would need to be deprecated now, continue
>> to be deprecated in 6.0 (at least one major in deprecated), then removed in
>> 7.0.
>>
>
>
> This is technically true.  But I don't think we need to be explicitly
> deprecating jdk versions.  Users are generally aware of Java's LTS cycle,
> and we can document this separately.
>
> Where we are bound is that our upgrade tests require an overlapping common
> jdk.  So we can only test upgrades that support a common jdk.  And 🥁
>  IMHO, we should not be saying we recommend/support upgrades that we don't
> test (regardless if not having broken compatibility means we think untested
> upgrade paths would still work).   If 5.0 supports 17, then 7.0 should too,
> if we are to say we support 5.0 to 7.0 upgrades.
>
>

Re: [VOTE] Simplifying our release versioning process

[Josh McKenzie]

Pragmatically, I believe our in-jvm upgrade dtests require the 2 versions of C* 
you're testing to both support running on (and probably right now building on) 
a shared JDK version. So for instance, if we had:

- Release 21.0.0: JDK30, JDK31
- Release 22.0.0: JDK35, JDK40

We wouldn't be able to test an upgrade from 21 to 22. Arguably we could *build* 
on an older supported version and run both on the newer, but at least right now 
I think that's our restriction. There's tension here if our release cadence and 
LTS JDK's intersect badly, but JDK LTS is infrequent enough relative to our 
releases that I think we're potentially getting worked up about a non-issue 
here.

Since the JDK isn't an API and we've already discussed and have some measure of 
consensus in the past (I thought; haven't dug that up now due to shortage of 
time), I think we can and should formalize that separately from this vote 
thread.

On Wed, Apr 23, 2025, at 6:31 PM, David Capwell wrote:
>> Also, I thought we had separate discussion about them - that we want to keep 
>> up possibly with the last two LTS versions.
> 
> This is what I remember as well.  6.0 would support 17/21 as thats the 
> latest, if 7.0 is out before 25, then 7.0 would be 17/21, else it would be 
> 21/25
> 
>> On Apr 23, 2025, at 3:11 PM, Ekaterina Dimitrova  
>> wrote:
>> 
>> I should say that I also haven’t thought of JDK versions when I voted here. 
>> Also, I thought we had separate discussion about them - that we want to keep 
>> up possibly with the last two LTS versions. Currently we do not have vision 
>> on when will be the next release date, so I cannot personally align JDK LTS 
>> versions to our versioning. Also, depends on people availability and testing 
>> resources when and what versions we will maintain our builds with. (And when 
>> and what Cassandra releases we will have, too)
>> 
>> Regarding the - “do not change what we vote for in the middle of the vote” - 
>> I agree, this is not the way to do it. But honestly I did not perceive this 
>> voting as such a case. I also knew about the agreement that any breaking 
>> changes will be discussed on the dev mailing list prior removal and we try 
>> to be backward compatible as much as possible. 
>> 
>> On Wed, 23 Apr 2025 at 18:02, Jeremiah Jordan  wrote:
>>> > The JVM version also isn’t a feature to deprecate, technically. 
>>> I agree with this. I think the JVM version the server runs under and how we 
>>> cycle those is a separate discussion from feature deprecation.
>>> 
>>> There can and has been some overlap there that would need to be handled on 
>>> a case by case basis (when a new JVM removed something that we did not have 
>>> a good way to keep doing without it, talking about you scripting runtime 
>>> based UDFs), but in general I don’t think switching JVMs is the same as 
>>> feature removal/deprecation.
>>> 
>>> -Jeremiah
>>> 
>>> 
>>> On Wed, Apr 23, 2025 at 4:48 PM Jordan West  wrote:
 I agree with Jon that I’m now a bit confused on part of what I voted for. 
 It feels like there is more discussion to be had here. Or we need to split 
 it into two votes if we want to make progress on the part where there is 
 consensus and revisit where there is not. 
 
 Regarding JVM version what I’ve mostly seen as reasons against forcing a 
 JVM upgrade with a C* upgrade is risk tolerance. Folks bit by past 
 upgrades have a tendency to want to limit as many variables as possible. 
 From a technical perspective I’m not sure that’s justified tbh but having 
 been one of the folks wanting to reduce variables and still getting bit by 
 upgrades I understand it. The JVM version also isn’t a feature to 
 deprecate, technically. And having made the decision once to hold off on 
 upgrading the JVM and regretting it I too would like to see the project 
 try to keep pace with JVM releases instead of being on older LTS or 
 unsupported versions. 
 
 
 Jordan 
 
 On Wed, Apr 23, 2025 at 13:49 Jon Haddad  wrote:
> >   If 5.0 supports 17, then 7.0 should too, if we are to say we support 
> > 5.0 to 7.0 upgrades. 
> 
> I have to disagree with this.  I don't see a good reason have a tight 
> coupling of JVM versions to C* versions, and I also don't see a good 
> reason to overlap outside of CI.  Even on CI, the reasoning is a bit 
> weak, Linux distros have supported multiple JDK versions for at least a 
> decade (update-java-alternatives on Ubuntu and alternatives on RedHat).
> 
> I've heard several folks explain their reasoning for overlap in JVM 
> versions, and it just doesn't resonate with me when weighed against the 
> downsides of being anchored to the limitations imposed by supporting old 
> JVM versions.
> 
> I don't want this to come back and bite us later - so unless we're 
> exempting the JVM version from this upgrade requirement, I'm changing my 
> vot

Re: Python and Go callouts during ant compile/build task

[Alex Petrov]

> If you want to run check but skip it, it's to add `-Dant.gen-doc.skip=true`
I do not think developers have to be forced skip it. Such checks can be a part 
of CI or merge, but not a common development workflow. It should be in a 
separate task, and simply calling `ant` should most certainly not invoke it.

Besides, scripts should never implicitly install any third-party software. They 
may require or depend on some software, or have an option for opt-in 
installation, but not installing implicitly.

On Wed, Apr 23, 2025, at 10:36 PM, Mick Semb Wever wrote:
> Python and Go are used by the gen-doc target.
> 
> Code changes can break these, hence it is part of `ant check`.
> It is not called by `ant jar`
> 
> If you want to run check but skip it, it's to add `-Dant.gen-doc.skip=true`
> 
> 
> 
> On Wed, 23 Apr 2025 at 22:06, Alex Petrov  wrote:
>> __
>> Hi folks,
>> 
>> Building Cassandra jar has been getting increasingly slow, and now it looks 
>> like we depend not only on python3 (which was already not optimal), but also 
>> on go:
>> 
>> ant -Dno-checkstyle=true
>> 
>> ...
>> 
>>  [exec] python3 ./scripts/gen-nodetool-docs.py
>>  [exec] python3 ./scripts/convert_yaml_to_adoc.py ../conf/cassandra.yaml 
>> ./modules/cassandra/pages/managing/configuration/cass_yaml_file.adoc
>>  [exec] ./scripts/process-native-protocol-specs-in-docker.sh
>>  [exec] Go env not found in your system, proceeding with installation.
>>  [exec] Downloading Go 1.23.1...
>>  [exec] Installing Go 1.23.1...
>>  [exec] Building the cqlprotodoc...
>>  [exec] Cloning into 'cassandra-website'...
>>  [exec] Your branch is up to date with 'origin/trunk'.
>>  [exec] go: downloading github.com/mvdan/xurls v1.1.0
>>  [exec] Processing the .spec files...
>> 
>> I personally consider this extremely dangerous, but also unnecessary. My 
>> current stance is that functionality introducing python3 and go should be 
>> moved to a separate task that only runs on demand / ci / release.  I welcome 
>> convincing arguments that would suggest otherwise.
>> 
>> If you agree we should not require python and go to run `ant 
>> -Dno-checkstyle=true`, please also write a short message, this will be very 
>> helpful as well.
>> 
>> Thank you,
>> --Alex

Re: [VOTE] Simplifying our release versioning process

[Ekaterina Dimitrova]

I think there is no reason to deprecate 17 in 5.0?

I’d think we would deprecate at some point 11 in 5.0, (once the community
is confident in 17 being prod ready.)  We commit 21 in 6.0 with the plan to
remove 11 and switch to 17 builds in 6.0. Any other thoughts? Points of
view?

On Wed, 23 Apr 2025 at 13:42, Jon Haddad  wrote:

> So to be clear - are we simultaneously calling Java 17 in 5.0 deprecated
> AND experimental?
>
>
>
> On Wed, Apr 23, 2025 at 10:23 AM Joseph Lynch 
> wrote:
>
>> +1 given "Have it for *at least* 1 MAJOR in deprecated status
>> (deprecate-then-remove)"
>>
>> How does that sit with you Joey?
>>>
>> Great! Really appreciate the clarification!
>>
>> -Joey
>>
>

Re: Python and Go callouts during ant compile/build task

[Jordan West]

Should we consider making that the default and then passing false
explicitly in CI/builds? I agree with Alex it’s a bit surprising and
shorter build times when developing would be helpful.

Jordan

On Wed, Apr 23, 2025 at 13:37 Mick Semb Wever  wrote:

> Python and Go are used by the gen-doc target.
>
> Code changes can break these, hence it is part of `ant check`.
> It is not called by `ant jar`
>
> If you want to run check but skip it, it's to add `-Dant.gen-doc.skip=true`
>
>
>
> On Wed, 23 Apr 2025 at 22:06, Alex Petrov  wrote:
>
>> Hi folks,
>>
>> Building Cassandra jar has been getting increasingly slow, and now it
>> looks like we depend not only on python3 (which was already not optimal),
>> but also on go:
>>
>> ant -Dno-checkstyle=true
>>
>> ...
>>
>>  [exec] python3 ./scripts/gen-nodetool-docs.py
>>  [exec] python3 ./scripts/convert_yaml_to_adoc.py
>> ../conf/cassandra.yaml
>> ./modules/cassandra/pages/managing/configuration/cass_yaml_file.adoc
>>  [exec] ./scripts/process-native-protocol-specs-in-docker.sh
>>  [exec] Go env not found in your system, proceeding with installation.
>>  [exec] Downloading Go 1.23.1...
>>  [exec] Installing Go 1.23.1...
>>  [exec] Building the cqlprotodoc...
>>  [exec] Cloning into 'cassandra-website'...
>>  [exec] Your branch is up to date with 'origin/trunk'.
>>  [exec] go: downloading github.com/mvdan/xurls v1.1.0
>>  [exec] Processing the .spec files...
>>
>> I personally consider this extremely dangerous, but also unnecessary. My
>> current stance is that functionality introducing python3 and go should be
>> moved to a separate task that only runs on demand / ci / release.  I
>> welcome convincing arguments that would suggest otherwise.
>>
>> If you agree we should not require python and go to run `ant
>> -Dno-checkstyle=true`, please also write a short message, this will be very
>> helpful as well.
>>
>> Thank you,
>> --Alex
>>
>

Re: Python and Go callouts during ant compile/build task

[Mick Semb Wever]

Python and Go are used by the gen-doc target.

Code changes can break these, hence it is part of `ant check`.
It is not called by `ant jar`

If you want to run check but skip it, it's to add `-Dant.gen-doc.skip=true`



On Wed, 23 Apr 2025 at 22:06, Alex Petrov  wrote:

> Hi folks,
>
> Building Cassandra jar has been getting increasingly slow, and now it
> looks like we depend not only on python3 (which was already not optimal),
> but also on go:
>
> ant -Dno-checkstyle=true
>
> ...
>
>  [exec] python3 ./scripts/gen-nodetool-docs.py
>  [exec] python3 ./scripts/convert_yaml_to_adoc.py
> ../conf/cassandra.yaml
> ./modules/cassandra/pages/managing/configuration/cass_yaml_file.adoc
>  [exec] ./scripts/process-native-protocol-specs-in-docker.sh
>  [exec] Go env not found in your system, proceeding with installation.
>  [exec] Downloading Go 1.23.1...
>  [exec] Installing Go 1.23.1...
>  [exec] Building the cqlprotodoc...
>  [exec] Cloning into 'cassandra-website'...
>  [exec] Your branch is up to date with 'origin/trunk'.
>  [exec] go: downloading github.com/mvdan/xurls v1.1.0
>  [exec] Processing the .spec files...
>
> I personally consider this extremely dangerous, but also unnecessary. My
> current stance is that functionality introducing python3 and go should be
> moved to a separate task that only runs on demand / ci / release.  I
> welcome convincing arguments that would suggest otherwise.
>
> If you agree we should not require python and go to run `ant
> -Dno-checkstyle=true`, please also write a short message, this will be very
> helpful as well.
>
> Thank you,
> --Alex
>

Re: [VOTE] Simplifying our release versioning process

[Jeremiah Jordan]

> The JVM version also isn’t a feature to deprecate, technically.

I agree with this. I think the JVM version the server runs under and how we
cycle those is a separate discussion from feature deprecation.

There can and has been some overlap there that would need to be handled on
a case by case basis (when a new JVM removed something that we did not have
a good way to keep doing without it, talking about you scripting runtime
based UDFs), but in general I don’t think switching JVMs is the same as
feature removal/deprecation.

-Jeremiah


On Wed, Apr 23, 2025 at 4:48 PM Jordan West  wrote:

> I agree with Jon that I’m now a bit confused on part of what I voted for.
> It feels like there is more discussion to be had here. Or we need to split
> it into two votes if we want to make progress on the part where there is
> consensus and revisit where there is not.
>
> Regarding JVM version what I’ve mostly seen as reasons against forcing a
> JVM upgrade with a C* upgrade is risk tolerance. Folks bit by past upgrades
> have a tendency to want to limit as many variables as possible. From a
> technical perspective I’m not sure that’s justified tbh but having been one
> of the folks wanting to reduce variables and still getting bit by upgrades
> I understand it. The JVM version also isn’t a feature to deprecate,
> technically. And having made the decision once to hold off on upgrading the
> JVM and regretting it I too would like to see the project try to keep pace
> with JVM releases instead of being on older LTS or unsupported versions.
>
> Jordan
>
> On Wed, Apr 23, 2025 at 13:49 Jon Haddad  wrote:
>
>> >   If 5.0 supports 17, then 7.0 should too, if we are to say we support
>> 5.0 to 7.0 upgrades.
>>
>> I have to disagree with this.  I don't see a good reason have a tight
>> coupling of JVM versions to C* versions, and I also don't see a good reason
>> to overlap outside of CI.  Even on CI, the reasoning is a bit weak, Linux
>> distros have supported multiple JDK versions for at least a decade
>> (update-java-alternatives on Ubuntu and alternatives on RedHat).
>>
>> I've heard several folks explain their reasoning for overlap in JVM
>> versions, and it just doesn't resonate with me when weighed against the
>> downsides of being anchored to the limitations imposed by supporting old
>> JVM versions.
>>
>> I don't want this to come back and bite us later - so unless we're
>> exempting the JVM version from this upgrade requirement, I'm changing my
>> vote to  -1.
>>
>> Furthermore, really shouldn't be changing the terms of the thing we're
>> voting on mid-vote.  This feels really weird to me.  Anyone who cast a vote
>> previously may not be keeping up with the ML on a daily basis and it's not
>> fair to impose changes on them.  People should be aware of what they're
>> voting for and not be surprised when the VOTE is closed.
>>
>> Jon
>>
>>
>>
>> On Wed, Apr 23, 2025 at 1:04 PM Mick Semb Wever  wrote:
>>
>>>.
>>>

 This reads to me that Java 17 would need to be deprecated now, continue
 to be deprecated in 6.0 (at least one major in deprecated), then removed in
 7.0.

>>>
>>>
>>> This is technically true.  But I don't think we need to be explicitly
>>> deprecating jdk versions.  Users are generally aware of Java's LTS cycle,
>>> and we can document this separately.
>>>
>>> Where we are bound is that our upgrade tests require an overlapping
>>> common jdk.  So we can only test upgrades that support a common jdk.  And
>>> 🥁  IMHO, we should not be saying we recommend/support upgrades that we
>>> don't test (regardless if not having broken compatibility means we think
>>> untested upgrade paths would still work).   If 5.0 supports 17, then 7.0
>>> should too, if we are to say we support 5.0 to 7.0 upgrades.
>>>
>>>
>>

Slack channel - invitation

[SteuerJ]

Hi all,

please can you invite me to the Slack Cassandra channel (I do not have @
apache.org email, I prefer access via *steuer.j...@gmail.com
*).

Many thanks

J. Steuer

Re: [VOTE] Simplifying our release versioning process

[Josh McKenzie]

> Can we just remove the parenthetical in #4 or clarify that breaking changes 
> require a minimum duration as determined by a DISCUSS thread - not to be 
> shorter than 1 major release?
The text we're voting on right now leaves us flexible on:
 1. What we decide to "API Break"
 2. How we decide to "API Break"
We reached a consensus on that previous discussion of "hit dev ML with 
[DISCUSS] for any API introduction or removal", so I *think* we're good with 
the text here as written and don't need to revise and re-call the vote.

While strictly the text as written confines us to a deprecate in N then remove 
in N+1 MAJOR, the combination of this with our consensus on our default posture 
as "never break API if we can help it" means that the only situations in which 
we actually need to break an API would be extreme circumstances (unworkable 
lossy API, security risk, etc) where deprecating then removing in next MAJOR 
would make sense.

To distill:
 • Try never to break API
 • In the rare case we *have* to break an API, we need to:
   • Have a dev ml [DISCUSS] thread about it w/consensus
   • Have it for at least 1 MAJOR in deprecated status (deprecate-then-remove)
   • Then remove in N+1
That'd probably end up being at a minimum 12 months since that's our time 
between majors.

How does that sit with you Joey?

On Wed, Apr 23, 2025, at 11:49 AM, Bernardo Botella wrote:
> +1
> 
>> On Apr 22, 2025, at 7:20 PM, Joseph Lynch  wrote:
>> 
>> I'm unclear if Josh/Ekaterina/Benedict's statements are part of the vote 
>> amending our project governance. If consensus is required for breaking 
>> changes with a strong preference for not breaking I am +1, but the original 
>> text of Josh's proposal is merely "We use a deprecate-then-remove strategy 
>> for API breaking changes (deprecate in release N, then remove in N+1)" and I 
>> don't see anything in the linked Governance page referring to this discuss 
>> policy on breaking changes.
>> 
>> Can we just remove the parenthetical in #4 or clarify that breaking changes 
>> require a minimum duration as determined by a DISCUSS thread - not to be 
>> shorter than 1 major release?
>> 
>> -Joey
>> 
>> On Tue, Apr 22, 2025 at 6:17 PM Patrick McFadin  wrote:
>>> +1
>>> 
>>> On Tue, Apr 22, 2025 at 8:52 AM Dmitry Konstantinov  
>>> wrote:
 +1
 
 On Tue, 22 Apr 2025 at 16:37, Caleb Rackliffe  
 wrote:
> +1
> 
> On Tue, Apr 22, 2025 at 8:37 AM Ekaterina Dimitrova 
>  wrote:
>> +1
>> 
>> I also remember we agreed on Discuss thread for removing anything plus 
>> preference for backward compatibility wherever it is possible. 
>> 
>> On Tue, 22 Apr 2025 at 7:00, Sam Tunnicliffe  wrote:
>>> +1
>>> 
>>> > On 17 Apr 2025, at 16:58, Josh McKenzie  wrote:
>>> > 
>>> > [DISCUSS] thread: 
>>> > https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq
>>> > 
>>> > The proposed new versioning mechanism:
>>> > • We no longer use semver .MINOR
>>> > • Online upgrades are supported for all GA supported releases at 
>>> > time of new .MAJOR
>>> > • T-1 releases are guaranteed API compatible for non-deprecated 
>>> > features
>>> > • We use a deprecate-then-remove strategy for API breaking 
>>> > changes (deprecate in release N, then remove in N+1)
>>> > This would translate into the following for our upcoming releases 
>>> > (assuming 3 supported majors at all times):
>>> > • 6.0: 5.0, 4.1, 4.0 online upgrades are supported (grandfather 
>>> > window). We drop support for 4.0. API compatibility is guaranteed 
>>> > w/5.0
>>> > • 7.0: 6.0, 5.0, 4.1 online upgrades are supported (grandfather 
>>> > window). We drop support for 4.1. API compatibility is guaranteed 
>>> > w/6.0
>>> > • 8.0: 7.0, 6.0, 5.0 online upgrades are supported (fully on new 
>>> > paradigm). We drop support for 5.0. API compatibility guaranteed w/7.0
>>> > David asked the question:
>>> >> 
>>> >> 
>>> >> Does this imply that each release is allowed to make breaking 
>>> >> changes (assuming they followed the “correct” deprecation process)? 
>>> >> My first instinct is to not like this
>>> > 
>>> > Each release would be allowed to make breaking changes but only for 
>>> > features that have already been deprecated for one major release 
>>> > cycle.
>>> > 
>>> > This is a process change so as per our governance: 
>>> > https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Project+Governance,
>>> >  it'll require a super majority of 50% of the roll called PMC in 
>>> > favor. Current roll call is 21 so we need 11 pmc members to 
>>> > participate, 8 of which are in favor of the change.
>>> > 
>>> > I'll plan to leave the vote open until we hit enough participation to 
>>> > pass or fail it up to probably a couple weeks.
>>> 
 
 
 --
 

Re: [VOTE] Simplifying our release versioning process

[Joseph Lynch]

+1 given "Have it for *at least* 1 MAJOR in deprecated status
(deprecate-then-remove)"

How does that sit with you Joey?
>
Great! Really appreciate the clarification!

-Joey

Re: Slack channel - invitation

[SteuerJ]

Many thanks, regards

   Jiri

st 23. 4. 2025 v 14:00 odesílatel Brandon Williams 
napsal:

> I've sent you an invitation.
>
> Kind Regards,
> Brandon
>
> On Wed, Apr 23, 2025 at 6:59 AM SteuerJ  wrote:
> >
> > Hi all,
> >
> > please can you invite me to the Slack Cassandra channel (I do not have @
> apache.org email, I prefer access via steuer.j...@gmail.com).
> >
> > Many thanks
> >
> > J. Steuer
>

Re: [VOTE] Simplifying our release versioning process

[Bernardo Botella]

+1

> On Apr 22, 2025, at 7:20 PM, Joseph Lynch  wrote:
> 
> I'm unclear if Josh/Ekaterina/Benedict's statements are part of the vote 
> amending our project governance. If consensus is required for breaking 
> changes with a strong preference for not breaking I am +1, but the original 
> text of Josh's proposal is merely "We use a deprecate-then-remove strategy 
> for API breaking changes (deprecate in release N, then remove in N+1)" and I 
> don't see anything in the linked Governance page referring to this discuss 
> policy on breaking changes.
> 
> Can we just remove the parenthetical in #4 or clarify that breaking changes 
> require a minimum duration as determined by a DISCUSS thread - not to be 
> shorter than 1 major release?
> 
> -Joey
> 
> On Tue, Apr 22, 2025 at 6:17 PM Patrick McFadin  > wrote:
>> +1
>> 
>> On Tue, Apr 22, 2025 at 8:52 AM Dmitry Konstantinov > > wrote:
>>> +1
>>> 
>>> On Tue, 22 Apr 2025 at 16:37, Caleb Rackliffe >> > wrote:
 +1
 
 On Tue, Apr 22, 2025 at 8:37 AM Ekaterina Dimitrova >>> > wrote:
> +1
> 
> I also remember we agreed on Discuss thread for removing anything plus 
> preference for backward compatibility wherever it is possible. 
> 
> On Tue, 22 Apr 2025 at 7:00, Sam Tunnicliffe  > wrote:
>> +1
>> 
>> > On 17 Apr 2025, at 16:58, Josh McKenzie > > > wrote:
>> > 
>> > [DISCUSS] thread: 
>> > https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq
>> > 
>> > The proposed new versioning mechanism:
>> > • We no longer use semver .MINOR
>> > • Online upgrades are supported for all GA supported releases at 
>> > time of new .MAJOR
>> > • T-1 releases are guaranteed API compatible for non-deprecated 
>> > features
>> > • We use a deprecate-then-remove strategy for API breaking changes 
>> > (deprecate in release N, then remove in N+1)
>> > This would translate into the following for our upcoming releases 
>> > (assuming 3 supported majors at all times):
>> > • 6.0: 5.0, 4.1, 4.0 online upgrades are supported (grandfather 
>> > window). We drop support for 4.0. API compatibility is guaranteed w/5.0
>> > • 7.0: 6.0, 5.0, 4.1 online upgrades are supported (grandfather 
>> > window). We drop support for 4.1. API compatibility is guaranteed w/6.0
>> > • 8.0: 7.0, 6.0, 5.0 online upgrades are supported (fully on new 
>> > paradigm). We drop support for 5.0. API compatibility guaranteed w/7.0
>> > David asked the question:
>> >> 
>> >> 
>> >> Does this imply that each release is allowed to make breaking changes 
>> >> (assuming they followed the “correct” deprecation process)? My first 
>> >> instinct is to not like this
>> > 
>> > Each release would be allowed to make breaking changes but only for 
>> > features that have already been deprecated for one major release cycle.
>> > 
>> > This is a process change so as per our governance: 
>> > https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Project+Governance,
>> >  it'll require a super majority of 50% of the roll called PMC in 
>> > favor. Current roll call is 21 so we need 11 pmc members to 
>> > participate, 8 of which are in favor of the change.
>> > 
>> > I'll plan to leave the vote open until we hit enough participation to 
>> > pass or fail it up to probably a couple weeks.
>> 
>> 
>>> 
>>> 
>>> 
>>> --
>>> Dmitry Konstantinov

Re: A Roadmap to Cassandra Analytics 1.0

[Doug Rohrer]

That’s great - thanks Štefan - please feel free to reach out in slack or via 
email if you’ve got any questions.

Doug

> On Apr 23, 2025, at 2:04 AM, Štefan Miklošovič  wrote:
> 
> Hi Doug,
> 
> I would love to help you with some of that. Spark 4.0 support seems appealing 
> to me. Let me check with my "backend" if there is any capacity doing so and 
> connecting privately to hash out the details.
> 
> Regards
> 
> On Tue, Apr 22, 2025 at 7:53 PM Doug Rohrer  > wrote:
>> Hello folks,
>> 
>> As many of you on the ASF Slack may have noticed, I’ve been creating a bunch 
>> of new tickets for the Cassandra Analytics project related to a 1.0 release. 
>> Since it was initially contributed, there have been many enhancements and 
>> fixes to the library, but there are still some gaps that need to be 
>> addressed. We’re putting together a plan to close those gaps, and would love 
>> to enlist more folks from the community in making the analytics library more 
>> useful. The gaps we see today include:
>> vnode support (and optimizations to the exiting code if necessary to make it 
>> work more efficiently with clusters using vnodes) (CASSANALYTICS-10 
>> )
>> Cassandra 5.0 support (this is an epic with lots of subtasks, some of which 
>> are already being worked on by a variety of folks) (CASSANALYTICS-23 
>> )
>> Documentation, including both docs on cassandra.apache.org 
>>  and updated/improved developer docs in the 
>> repository itself (CASSANALYTICS-6 
>> )
>> Build scripts for release (CASSANALYTICS-22 
>> )
>> Miscellaneous bug fixes of known issues/improvements
>> Analytics writer should support all valid partition/clustering key types 
>> (CASSANALYTICS-35 )
>> CassandraDataLayer uses configuration list of IPs instead of the full 
>> ring/datacenter (CASSANALYTICS-20 
>> )
>> Bulk Reader should dynamically calculate number of cores to use to better 
>> utilize resources for smaller tables (CASSANALYTICS-36 
>> )
>> 
>> Beyond 1.0, there’s a lot of improvements and enhancements on the roadmap to 
>> date:
>> Cassandra 6.0 Support (CASSANALYTICS-37 
>> )
>> Spark 4.0 support (CASSANALYTICS-34 
>> )
>> JDK Support Matrix (CASSANALYTICS-38 
>> )
>> Improved Compaction/Repair load for bulk writes (CASSANALYTICS-39 
>> )
>> Bandwidth reduction (especially cross-dc writes) (CASSANALYTICS-40 
>> )
>> Consolidation of SBW-on-S3 and DIRECT mode code (CASSANALYTICS-41 
>> )
>> Bulk reads via S3 (CASSANALYTICS-42 
>> )
>> 
>> We’re also looking for input on what others think should be in the 1.0 
>> release, or the long-term roadmap. If you’ve got ideas, don’t hesitate to 
>> respond to this thread. I’ll also be checking the existing JIRAs and making 
>> sure they are incorporated into the plan, which I believe most are already.
>> 
>> I want to thank the folks who have, so far, contributed most of the code for 
>> the Analytics library, and those in the community who have already started 
>> to use and improve it. We’re looking forward to getting more community 
>> members involved. If any of these items sounds interesting, please feel free 
>> to reach out to folks on Slack or reply on the dev list.
>> 
>> Thanks,
>> 
>> Doug Rohrer

Re: Slack channel - invitation

[Brandon Williams]

I've sent you an invitation.

Kind Regards,
Brandon

On Wed, Apr 23, 2025 at 6:59 AM SteuerJ  wrote:
>
> Hi all,
>
> please can you invite me to the Slack Cassandra channel (I do not have 
> @apache.org email, I prefer access via steuer.j...@gmail.com).
>
> Many thanks
>
> J. Steuer

Re: A Roadmap to Cassandra Analytics 1.0

[Doug Rohrer]

I put everything into Jira directly - there are two epics, one for the 
“Analytics 1.0 ” 
release and one for “Cassandra 5.0 support. 
”, figuring that once 
we started work on these things (which some folks actually have) a Confluence 
page would quickly become out of date.

If folks feel like there’s some value in putting something up there we could do 
that, but I think epics in Jira capture the plan fairly well.

Thanks,

Doug

> On Apr 22, 2025, at 6:15 PM, Patrick McFadin  wrote:
> 
> Is the current roadmap published somewhere? I went to Confluence and couldn't 
> find anything.
> 
> Patrick
> 
> On Tue, Apr 22, 2025 at 10:53 AM Doug Rohrer  > wrote:
>> Hello folks,
>> 
>> As many of you on the ASF Slack may have noticed, I’ve been creating a bunch 
>> of new tickets for the Cassandra Analytics project related to a 1.0 release. 
>> Since it was initially contributed, there have been many enhancements and 
>> fixes to the library, but there are still some gaps that need to be 
>> addressed. We’re putting together a plan to close those gaps, and would love 
>> to enlist more folks from the community in making the analytics library more 
>> useful. The gaps we see today include:
>> vnode support (and optimizations to the exiting code if necessary to make it 
>> work more efficiently with clusters using vnodes) (CASSANALYTICS-10 
>> )
>> Cassandra 5.0 support (this is an epic with lots of subtasks, some of which 
>> are already being worked on by a variety of folks) (CASSANALYTICS-23 
>> )
>> Documentation, including both docs on cassandra.apache.org 
>>  and updated/improved developer docs in the 
>> repository itself (CASSANALYTICS-6 
>> )
>> Build scripts for release (CASSANALYTICS-22 
>> )
>> Miscellaneous bug fixes of known issues/improvements
>> Analytics writer should support all valid partition/clustering key types 
>> (CASSANALYTICS-35 )
>> CassandraDataLayer uses configuration list of IPs instead of the full 
>> ring/datacenter (CASSANALYTICS-20 
>> )
>> Bulk Reader should dynamically calculate number of cores to use to better 
>> utilize resources for smaller tables (CASSANALYTICS-36 
>> )
>> 
>> Beyond 1.0, there’s a lot of improvements and enhancements on the roadmap to 
>> date:
>> Cassandra 6.0 Support (CASSANALYTICS-37 
>> )
>> Spark 4.0 support (CASSANALYTICS-34 
>> )
>> JDK Support Matrix (CASSANALYTICS-38 
>> )
>> Improved Compaction/Repair load for bulk writes (CASSANALYTICS-39 
>> )
>> Bandwidth reduction (especially cross-dc writes) (CASSANALYTICS-40 
>> )
>> Consolidation of SBW-on-S3 and DIRECT mode code (CASSANALYTICS-41 
>> )
>> Bulk reads via S3 (CASSANALYTICS-42 
>> )
>> 
>> We’re also looking for input on what others think should be in the 1.0 
>> release, or the long-term roadmap. If you’ve got ideas, don’t hesitate to 
>> respond to this thread. I’ll also be checking the existing JIRAs and making 
>> sure they are incorporated into the plan, which I believe most are already.
>> 
>> I want to thank the folks who have, so far, contributed most of the code for 
>> the Analytics library, and those in the community who have already started 
>> to use and improve it. We’re looking forward to getting more community 
>> members involved. If any of these items sounds interesting, please feel free 
>> to reach out to folks on Slack or reply on the dev list.
>> 
>> Thanks,
>> 
>> Doug Rohrer

Re: Python and Go callouts during ant compile/build task

[Alex Petrov]

I didn’t say we should disable checks. I thought this was a purpose of CI : to 
check everything: there’s likely more to break semantically anyways, also 
harder to detect and fix. I’m also not proposing removing something that was 
long in place, these dependencies were introduced very recently.

On Wed, Apr 23, 2025, at 11:51 PM, Jeremiah Jordan wrote:
> I think the default build should be to build and check everything.  I think 
> that if someone is new it is better to have everything built and checked by 
> default to flag issues.
> 
> If someone knows what they are doing and wants to speed up the process it is 
> very easy to add the right settings to the ant command so things are faster.
> 
> -Jeremiah
> 
> On Wed, Apr 23, 2025 at 4:36 PM Jordan West  wrote:
>> Should we consider making that the default and then passing false explicitly 
>> in CI/builds? I agree with Alex it’s a bit surprising and shorter build 
>> times when developing would be helpful. 
>> 
>> Jordan 
>> 
>> On Wed, Apr 23, 2025 at 13:37 Mick Semb Wever  wrote:
>>> Python and Go are used by the gen-doc target.
>>> 
>>> Code changes can break these, hence it is part of `ant check`.
>>> It is not called by `ant jar`
>>> 
>>> If you want to run check but skip it, it's to add `-Dant.gen-doc.skip=true`
>>> 
>>> 
>>> 
>>> On Wed, 23 Apr 2025 at 22:06, Alex Petrov  wrote:
 __
 Hi folks,
 
 Building Cassandra jar has been getting increasingly slow, and now it 
 looks like we depend not only on python3 (which was already not optimal), 
 but also on go:
 
 ant -Dno-checkstyle=true
 
 ...
 
  [exec] python3 ./scripts/gen-nodetool-docs.py
  [exec] python3 ./scripts/convert_yaml_to_adoc.py 
 ../conf/cassandra.yaml 
 ./modules/cassandra/pages/managing/configuration/cass_yaml_file.adoc
  [exec] ./scripts/process-native-protocol-specs-in-docker.sh
  [exec] Go env not found in your system, proceeding with installation.
  [exec] Downloading Go 1.23.1...
  [exec] Installing Go 1.23.1...
  [exec] Building the cqlprotodoc...
  [exec] Cloning into 'cassandra-website'...
  [exec] Your branch is up to date with 'origin/trunk'.
  [exec] go: downloading github.com/mvdan/xurls v1.1.0
  [exec] Processing the .spec files...
 
 I personally consider this extremely dangerous, but also unnecessary. My 
 current stance is that functionality introducing python3 and go should be 
 moved to a separate task that only runs on demand / ci / release.  I 
 welcome convincing arguments that would suggest otherwise.
 
 If you agree we should not require python and go to run `ant 
 -Dno-checkstyle=true`, please also write a short message, this will be 
 very helpful as well.
 
 Thank you,
 --Alex

Re: Python and Go callouts during ant compile/build task

[Mick Semb Wever]

Does this also apply to gradle, which now gets downloaded and installed,
and is the most recent addition ?

The python requirement from gen-doc has been around for over three years
now.

I agree with the rationale that `ant` should default to `ant check`,
keeping newcomers in mind while being more just a final pre-commit action
for seasoned devs where `ant jar` is the typical dev loop.  I'm sure this
has been discussed in the past.



On Thu, 24 Apr 2025 at 08:16, Alex Petrov  wrote:

> I didn’t say we should disable checks. I thought this was a purpose of CI
> : to check everything: there’s likely more to break semantically anyways,
> also harder to detect and fix. I’m also not proposing removing something
> that was long in place, these dependencies were introduced very recently.
>
> On Wed, Apr 23, 2025, at 11:51 PM, Jeremiah Jordan wrote:
>
> I think the default build should be to build and check everything.  I
> think that if someone is new it is better to have everything built and
> checked by default to flag issues.
>
> If someone knows what they are doing and wants to speed up the process it
> is very easy to add the right settings to the ant command so things are
> faster.
>
> -Jeremiah
>
> On Wed, Apr 23, 2025 at 4:36 PM Jordan West  wrote:
>
> Should we consider making that the default and then passing false
> explicitly in CI/builds? I agree with Alex it’s a bit surprising and
> shorter build times when developing would be helpful.
>
> Jordan
>
> On Wed, Apr 23, 2025 at 13:37 Mick Semb Wever  wrote:
>
> Python and Go are used by the gen-doc target.
>
> Code changes can break these, hence it is part of `ant check`.
> It is not called by `ant jar`
>
> If you want to run check but skip it, it's to add `-Dant.gen-doc.skip=true`
>
>
>
> On Wed, 23 Apr 2025 at 22:06, Alex Petrov  wrote:
>
>
> Hi folks,
>
> Building Cassandra jar has been getting increasingly slow, and now it
> looks like we depend not only on python3 (which was already not optimal),
> but also on go:
>
> ant -Dno-checkstyle=true
>
> ...
>
>  [exec] python3 ./scripts/gen-nodetool-docs.py
>  [exec] python3 ./scripts/convert_yaml_to_adoc.py
> ../conf/cassandra.yaml
> ./modules/cassandra/pages/managing/configuration/cass_yaml_file.adoc
>  [exec] ./scripts/process-native-protocol-specs-in-docker.sh
>  [exec] Go env not found in your system, proceeding with installation.
>  [exec] Downloading Go 1.23.1...
>  [exec] Installing Go 1.23.1...
>  [exec] Building the cqlprotodoc...
>  [exec] Cloning into 'cassandra-website'...
>  [exec] Your branch is up to date with 'origin/trunk'.
>  [exec] go: downloading github.com/mvdan/xurls v1.1.0
>  [exec] Processing the .spec files...
>
> I personally consider this extremely dangerous, but also unnecessary. My
> current stance is that functionality introducing python3 and go should be
> moved to a separate task that only runs on demand / ci / release.  I
> welcome convincing arguments that would suggest otherwise.
>
> If you agree we should not require python and go to run `ant
> -Dno-checkstyle=true`, please also write a short message, this will be very
> helpful as well.
>
> Thank you,
> --Alex
>
>
>

Re: [VOTE] Simplifying our release versioning process

[Jon Haddad]

Have it for *at least* 1 MAJOR in deprecated status (deprecate-then-remove)

This reads to me that Java 17 would need to be deprecated now, continue to
be deprecated in 6.0 (at least one major in deprecated), then removed in
7.0.



On Wed, Apr 23, 2025 at 10:54 AM Ekaterina Dimitrova 
wrote:

> I think there is no reason to deprecate 17 in 5.0?
>
> I’d think we would deprecate at some point 11 in 5.0, (once the community
> is confident in 17 being prod ready.)  We commit 21 in 6.0 with the plan to
> remove 11 and switch to 17 builds in 6.0. Any other thoughts? Points of
> view?
>
> On Wed, 23 Apr 2025 at 13:42, Jon Haddad  wrote:
>
>> So to be clear - are we simultaneously calling Java 17 in 5.0 deprecated
>> AND experimental?
>>
>>
>>
>> On Wed, Apr 23, 2025 at 10:23 AM Joseph Lynch 
>> wrote:
>>
>>> +1 given "Have it for *at least* 1 MAJOR in deprecated status
>>> (deprecate-then-remove)"
>>>
>>> How does that sit with you Joey?

>>> Great! Really appreciate the clarification!
>>>
>>> -Joey
>>>
>>

Re: [VOTE] Simplifying our release versioning process

[Mick Semb Wever]

.

>
> This reads to me that Java 17 would need to be deprecated now, continue to
> be deprecated in 6.0 (at least one major in deprecated), then removed in
> 7.0.
>


This is technically true.  But I don't think we need to be explicitly
deprecating jdk versions.  Users are generally aware of Java's LTS cycle,
and we can document this separately.

Where we are bound is that our upgrade tests require an overlapping common
jdk.  So we can only test upgrades that support a common jdk.  And 🥁
 IMHO, we should not be saying we recommend/support upgrades that we don't
test (regardless if not having broken compatibility means we think untested
upgrade paths would still work).   If 5.0 supports 17, then 7.0 should too,
if we are to say we support 5.0 to 7.0 upgrades.

Python and Go callouts during ant compile/build task

[Alex Petrov]

Hi folks,

Building Cassandra jar has been getting increasingly slow, and now it looks 
like we depend not only on python3 (which was already not optimal), but also on 
go:

ant -Dno-checkstyle=true

...

 [exec] python3 ./scripts/gen-nodetool-docs.py
 [exec] python3 ./scripts/convert_yaml_to_adoc.py ../conf/cassandra.yaml 
./modules/cassandra/pages/managing/configuration/cass_yaml_file.adoc
 [exec] ./scripts/process-native-protocol-specs-in-docker.sh
 [exec] Go env not found in your system, proceeding with installation.
 [exec] Downloading Go 1.23.1...
 [exec] Installing Go 1.23.1...
 [exec] Building the cqlprotodoc...
 [exec] Cloning into 'cassandra-website'...
 [exec] Your branch is up to date with 'origin/trunk'.
 [exec] go: downloading github.com/mvdan/xurls v1.1.0
 [exec] Processing the .spec files...

I personally consider this extremely dangerous, but also unnecessary. My 
current stance is that functionality introducing python3 and go should be moved 
to a separate task that only runs on demand / ci / release.  I welcome 
convincing arguments that would suggest otherwise. 

If you agree we should not require python and go to run `ant 
-Dno-checkstyle=true`, please also write a short message, this will be very 
helpful as well.

Thank you,
--Alex

Re: [VOTE] Simplifying our release versioning process

[David Capwell]

> Also, I thought we had separate discussion about them - that we want to keep 
> up possibly with the last two LTS versions.

This is what I remember as well.  6.0 would support 17/21 as thats the latest, 
if 7.0 is out before 25, then 7.0 would be 17/21, else it would be 21/25

> On Apr 23, 2025, at 3:11 PM, Ekaterina Dimitrova  
> wrote:
> 
> I should say that I also haven’t thought of JDK versions when I voted here. 
> Also, I thought we had separate discussion about them - that we want to keep 
> up possibly with the last two LTS versions. Currently we do not have vision 
> on when will be the next release date, so I cannot personally align JDK LTS 
> versions to our versioning. Also, depends on people availability and testing 
> resources when and what versions we will maintain our builds with. (And when 
> and what Cassandra releases we will have, too)
> 
> Regarding the - “do not change what we vote for in the middle of the vote” - 
> I agree, this is not the way to do it. But honestly I did not perceive this 
> voting as such a case. I also knew about the agreement that any breaking 
> changes will be discussed on the dev mailing list prior removal and we try to 
> be backward compatible as much as possible. 
> 
> On Wed, 23 Apr 2025 at 18:02, Jeremiah Jordan  > wrote:
>> > The JVM version also isn’t a feature to deprecate, technically. 
>> 
>> I agree with this. I think the JVM version the server runs under and how we 
>> cycle those is a separate discussion from feature deprecation.
>> 
>> There can and has been some overlap there that would need to be handled on a 
>> case by case basis (when a new JVM removed something that we did not have a 
>> good way to keep doing without it, talking about you scripting runtime based 
>> UDFs), but in general I don’t think switching JVMs is the same as feature 
>> removal/deprecation.
>> 
>> -Jeremiah
>> 
>> 
>> On Wed, Apr 23, 2025 at 4:48 PM Jordan West > > wrote:
>>> I agree with Jon that I’m now a bit confused on part of what I voted for. 
>>> It feels like there is more discussion to be had here. Or we need to split 
>>> it into two votes if we want to make progress on the part where there is 
>>> consensus and revisit where there is not. 
>>> 
>>> Regarding JVM version what I’ve mostly seen as reasons against forcing a 
>>> JVM upgrade with a C* upgrade is risk tolerance. Folks bit by past upgrades 
>>> have a tendency to want to limit as many variables as possible. From a 
>>> technical perspective I’m not sure that’s justified tbh but having been one 
>>> of the folks wanting to reduce variables and still getting bit by upgrades 
>>> I understand it. The JVM version also isn’t a feature to deprecate, 
>>> technically. And having made the decision once to hold off on upgrading the 
>>> JVM and regretting it I too would like to see the project try to keep pace 
>>> with JVM releases instead of being on older LTS or unsupported versions. 
>>> 
>>> Jordan 
>>> 
>>> On Wed, Apr 23, 2025 at 13:49 Jon Haddad >> > wrote:
 >   If 5.0 supports 17, then 7.0 should too, if we are to say we support 
 > 5.0 to 7.0 upgrades. 
 
 I have to disagree with this.  I don't see a good reason have a tight 
 coupling of JVM versions to C* versions, and I also don't see a good 
 reason to overlap outside of CI.  Even on CI, the reasoning is a bit weak, 
 Linux distros have supported multiple JDK versions for at least a decade 
 (update-java-alternatives on Ubuntu and alternatives on RedHat).
 
 I've heard several folks explain their reasoning for overlap in JVM 
 versions, and it just doesn't resonate with me when weighed against the 
 downsides of being anchored to the limitations imposed by supporting old 
 JVM versions.
 
 I don't want this to come back and bite us later - so unless we're 
 exempting the JVM version from this upgrade requirement, I'm changing my 
 vote to  -1. 
 
 Furthermore, really shouldn't be changing the terms of the thing we're 
 voting on mid-vote.  This feels really weird to me.  Anyone who cast a 
 vote previously may not be keeping up with the ML on a daily basis and 
 it's not fair to impose changes on them.  People should be aware of what 
 they're voting for and not be surprised when the VOTE is closed.
 
 Jon
 
 
 
 On Wed, Apr 23, 2025 at 1:04 PM Mick Semb Wever >>> > wrote:
>.
>   
>> 
>> This reads to me that Java 17 would need to be deprecated now, continue 
>> to be deprecated in 6.0 (at least one major in deprecated), then removed 
>> in 7.0. 
> 
> 
> This is technically true.  But I don't think we need to be explicitly 
> deprecating jdk versions.  Users are generally aware of Java's LTS cycle, 
> and we can document this separately.
> 
> Where we are boun

Re: [VOTE] Simplifying our release versioning process

[Jon Haddad]

So to be clear - are we simultaneously calling Java 17 in 5.0 deprecated
AND experimental?



On Wed, Apr 23, 2025 at 10:23 AM Joseph Lynch  wrote:

> +1 given "Have it for *at least* 1 MAJOR in deprecated status
> (deprecate-then-remove)"
>
> How does that sit with you Joey?
>>
> Great! Really appreciate the clarification!
>
> -Joey
>

Re: [UPDATE] CEP-37

[Jaydeep Chovatia]

The CEP-37 work has been successfully merged into the trunk today! Please
let me know if you have any issues.

This merge is a massive win for Apache Cassandra — a significant step
forward. But we're not stopping here. There's more to come, and we are
committed to pushing repair automation even further and closing the gaps in
the remaining flows. A few examples:

   1. Automatically running repair as part of the node replacement: Design
   

   & POC  is already
   out [CASSANDRA-20281
   ]
   2. Stopping repair automatically between Cassandra major version
   upgrades [CASSANDRA-20048
   ]
   3. Repairing automatically when Keyspace replication changes [
   CASSANDRA-20582 ]


Thanks for all the help and support from the Apache Cassandra community!

Yours sincerely,
Andy Tolbert, Chris Lohfink, Francisco Guerrero, Kristijonas Zalys, and
Jaydeep

On Sun, Mar 9, 2025 at 8:53 PM Jaydeep Chovatia 
wrote:

> Thanks a lot, Jon!
> This has truly been a team effort, with Andy Tolbert, Chris Lohfink,
> Francisco Guerrero, and Kristijonas Zalys all contributing over the past
> year. The credit belongs to everyone!
>
> Jaydeep
>
>
>
>
>
> On Sun, Mar 9, 2025 at 2:35 PM Jon Haddad  wrote:
>
>> This is all really exciting.  Getting a built in, orchestrated repair is
>> a massive achievement.  Thank you for your work on this, it's incredibly
>> valuable to the community!!
>>
>> Jon
>>
>> On Sun, Mar 9, 2025 at 2:25 PM Jaydeep Chovatia <
>> chovatia.jayd...@gmail.com> wrote:
>>
>>> No problem, Dave! Thank you.
>>>
>>> Jaydeep
>>>
>>> On Sun, Mar 9, 2025 at 10:46 AM Dave Herrington 
>>> wrote:
>>>
 Jaydeep,

 Thank you for taking time to answer my questions and for the links to
 the design and overview docs, which are excellent and answer all of my
 remaining questions.  Sorry I missed those links in the CEP page.

 Great work and I will continue to follow your progress on this powerful
 new feature.

 Thanks!
 -Dave

 On Sat, Mar 8, 2025 at 9:36 AM Jaydeep Chovatia <
 chovatia.jayd...@gmail.com> wrote:

> Hi David,
>
> Thanks for the kind words!
>
> >Is there a goal in this CEP to make automated repair work during
> rolling upgrades, when multiple versions exist in the cluster?
> We debated a lot on this over ASF Slack
> (#cassandra-repair-scheduling-cep37). The summary is that, ideally, we 
> want
> to have a repair function during the mixed version, but the reality is 
> that
> currently, there is no test suite available inside Apache Cassandra to
> verify the streaming behavior during the mixed version, so the confidence
> is low.
> We agreed on the following: 1) Keeping safety in mind, we should by
> default disable the repair during mixed version 2) Add a comprehensive 
> test
> suite 3) Allow repair during mixed version. Currently, we are at #1
>
> >Would automated repair be smart enough to automatically stop, if it
> sees incompatible versions?
> That's the plan, and we already have PR (CASSANDRA-20048
> ) out from
> Chris Lohfink. The thing we are debating is whether to stop only during
> major version mismatch or also during the minor version, and we are 
> leaning
> towards only disabling for the major version mismatch. Regardless, this
> should be available soon.
> We are also extending this further as per feedback from David
> Capwell that we should automatically stop repair if we detect a new DC or
> keyspace RF is changed. That will be covered later as part of
> CASSANDRA-20414
> 
>
> >If automated repair must be disabled for the entire cluster, will
> this be a single nodetool command, or must automated repair be disabled on
> each node individually?
> Yes, it is a nodetool command and does not require any restarts! All
> the *nodetool* command details are currently covered in the design doc
> ,
> and the same details will also be available in the Cassandra
> overview.adoc
> 
> .
>
> >Would it make sense for automated repair to upgrade sstables, if it
> finds old formats? (Maybe this could be a feature that could be optionally
> enabled?)
> My opinion is that it should not be part of 

Re: [UPDATE] CEP-37

[Jordan West]

Great work all! Another awesome milestone and huge step forward for the
project!

On Wed, Apr 23, 2025 at 12:47 Jaydeep Chovatia 
wrote:

> The CEP-37 work has been successfully merged into the trunk today! Please
> let me know if you have any issues.
>
> This merge is a massive win for Apache Cassandra — a significant step
> forward. But we're not stopping here. There's more to come, and we are
> committed to pushing repair automation even further and closing the gaps in
> the remaining flows. A few examples:
>
>1. Automatically running repair as part of the node replacement: Design
>
> 
>& POC  is
>already out [CASSANDRA-20281
>]
>2. Stopping repair automatically between Cassandra major version
>upgrades [CASSANDRA-20048
>]
>3. Repairing automatically when Keyspace replication changes [
>CASSANDRA-20582 ]
>
>
> Thanks for all the help and support from the Apache Cassandra community!
>
> Yours sincerely,
> Andy Tolbert, Chris Lohfink, Francisco Guerrero, Kristijonas Zalys, and
> Jaydeep
>
> On Sun, Mar 9, 2025 at 8:53 PM Jaydeep Chovatia <
> chovatia.jayd...@gmail.com> wrote:
>
>> Thanks a lot, Jon!
>> This has truly been a team effort, with Andy Tolbert, Chris Lohfink,
>> Francisco Guerrero, and Kristijonas Zalys all contributing over the past
>> year. The credit belongs to everyone!
>>
>> Jaydeep
>>
>>
>>
>>
>>
>> On Sun, Mar 9, 2025 at 2:35 PM Jon Haddad 
>> wrote:
>>
>>> This is all really exciting.  Getting a built in, orchestrated repair is
>>> a massive achievement.  Thank you for your work on this, it's incredibly
>>> valuable to the community!!
>>>
>>> Jon
>>>
>>> On Sun, Mar 9, 2025 at 2:25 PM Jaydeep Chovatia <
>>> chovatia.jayd...@gmail.com> wrote:
>>>
 No problem, Dave! Thank you.

 Jaydeep

 On Sun, Mar 9, 2025 at 10:46 AM Dave Herrington 
 wrote:

> Jaydeep,
>
> Thank you for taking time to answer my questions and for the links to
> the design and overview docs, which are excellent and answer all of my
> remaining questions.  Sorry I missed those links in the CEP page.
>
> Great work and I will continue to follow your progress on this
> powerful new feature.
>
> Thanks!
> -Dave
>
> On Sat, Mar 8, 2025 at 9:36 AM Jaydeep Chovatia <
> chovatia.jayd...@gmail.com> wrote:
>
>> Hi David,
>>
>> Thanks for the kind words!
>>
>> >Is there a goal in this CEP to make automated repair work during
>> rolling upgrades, when multiple versions exist in the cluster?
>> We debated a lot on this over ASF Slack
>> (#cassandra-repair-scheduling-cep37). The summary is that, ideally, we 
>> want
>> to have a repair function during the mixed version, but the reality is 
>> that
>> currently, there is no test suite available inside Apache Cassandra to
>> verify the streaming behavior during the mixed version, so the confidence
>> is low.
>> We agreed on the following: 1) Keeping safety in mind, we should by
>> default disable the repair during mixed version 2) Add a comprehensive 
>> test
>> suite 3) Allow repair during mixed version. Currently, we are at #1
>>
>> >Would automated repair be smart enough to automatically stop, if it
>> sees incompatible versions?
>> That's the plan, and we already have PR (CASSANDRA-20048
>> ) out from
>> Chris Lohfink. The thing we are debating is whether to stop only during
>> major version mismatch or also during the minor version, and we are 
>> leaning
>> towards only disabling for the major version mismatch. Regardless, this
>> should be available soon.
>> We are also extending this further as per feedback from David
>> Capwell that we should automatically stop repair if we detect a new DC or
>> keyspace RF is changed. That will be covered later as part of
>> CASSANDRA-20414
>> 
>>
>> >If automated repair must be disabled for the entire cluster, will
>> this be a single nodetool command, or must automated repair be disabled 
>> on
>> each node individually?
>> Yes, it is a nodetool command and does not require any restarts! All
>> the *nodetool* command details are currently covered in the design
>> doc
>> ,
>> and the same details will also be available in the Cassandra
>> overview.adoc
>> 

Re: [VOTE] Simplifying our release versioning process

[Jordan West]

I agree with Jon that I’m now a bit confused on part of what I voted for.
It feels like there is more discussion to be had here. Or we need to split
it into two votes if we want to make progress on the part where there is
consensus and revisit where there is not.

Regarding JVM version what I’ve mostly seen as reasons against forcing a
JVM upgrade with a C* upgrade is risk tolerance. Folks bit by past upgrades
have a tendency to want to limit as many variables as possible. From a
technical perspective I’m not sure that’s justified tbh but having been one
of the folks wanting to reduce variables and still getting bit by upgrades
I understand it. The JVM version also isn’t a feature to deprecate,
technically. And having made the decision once to hold off on upgrading the
JVM and regretting it I too would like to see the project try to keep pace
with JVM releases instead of being on older LTS or unsupported versions.

Jordan

On Wed, Apr 23, 2025 at 13:49 Jon Haddad  wrote:

> >   If 5.0 supports 17, then 7.0 should too, if we are to say we support
> 5.0 to 7.0 upgrades.
>
> I have to disagree with this.  I don't see a good reason have a tight
> coupling of JVM versions to C* versions, and I also don't see a good reason
> to overlap outside of CI.  Even on CI, the reasoning is a bit weak, Linux
> distros have supported multiple JDK versions for at least a decade
> (update-java-alternatives on Ubuntu and alternatives on RedHat).
>
> I've heard several folks explain their reasoning for overlap in JVM
> versions, and it just doesn't resonate with me when weighed against the
> downsides of being anchored to the limitations imposed by supporting old
> JVM versions.
>
> I don't want this to come back and bite us later - so unless we're
> exempting the JVM version from this upgrade requirement, I'm changing my
> vote to  -1.
>
> Furthermore, really shouldn't be changing the terms of the thing we're
> voting on mid-vote.  This feels really weird to me.  Anyone who cast a vote
> previously may not be keeping up with the ML on a daily basis and it's not
> fair to impose changes on them.  People should be aware of what they're
> voting for and not be surprised when the VOTE is closed.
>
> Jon
>
>
>
> On Wed, Apr 23, 2025 at 1:04 PM Mick Semb Wever  wrote:
>
>>.
>>
>>>
>>> This reads to me that Java 17 would need to be deprecated now, continue
>>> to be deprecated in 6.0 (at least one major in deprecated), then removed in
>>> 7.0.
>>>
>>
>>
>> This is technically true.  But I don't think we need to be explicitly
>> deprecating jdk versions.  Users are generally aware of Java's LTS cycle,
>> and we can document this separately.
>>
>> Where we are bound is that our upgrade tests require an overlapping
>> common jdk.  So we can only test upgrades that support a common jdk.  And
>> 🥁  IMHO, we should not be saying we recommend/support upgrades that we
>> don't test (regardless if not having broken compatibility means we think
>> untested upgrade paths would still work).   If 5.0 supports 17, then 7.0
>> should too, if we are to say we support 5.0 to 7.0 upgrades.
>>
>>
>

Re: Python and Go callouts during ant compile/build task

[Jeremiah Jordan]

I think the default build should be to build and check everything.  I think
that if someone is new it is better to have everything built and checked by
default to flag issues.

If someone knows what they are doing and wants to speed up the process it
is very easy to add the right settings to the ant command so things are
faster.

-Jeremiah

On Wed, Apr 23, 2025 at 4:36 PM Jordan West  wrote:

> Should we consider making that the default and then passing false
> explicitly in CI/builds? I agree with Alex it’s a bit surprising and
> shorter build times when developing would be helpful.
>
> Jordan
>
> On Wed, Apr 23, 2025 at 13:37 Mick Semb Wever  wrote:
>
>> Python and Go are used by the gen-doc target.
>>
>> Code changes can break these, hence it is part of `ant check`.
>> It is not called by `ant jar`
>>
>> If you want to run check but skip it, it's to add
>> `-Dant.gen-doc.skip=true`
>>
>>
>>
>> On Wed, 23 Apr 2025 at 22:06, Alex Petrov  wrote:
>>
>>> Hi folks,
>>>
>>> Building Cassandra jar has been getting increasingly slow, and now it
>>> looks like we depend not only on python3 (which was already not optimal),
>>> but also on go:
>>>
>>> ant -Dno-checkstyle=true
>>>
>>> ...
>>>
>>>  [exec] python3 ./scripts/gen-nodetool-docs.py
>>>  [exec] python3 ./scripts/convert_yaml_to_adoc.py
>>> ../conf/cassandra.yaml
>>> ./modules/cassandra/pages/managing/configuration/cass_yaml_file.adoc
>>>  [exec] ./scripts/process-native-protocol-specs-in-docker.sh
>>>  [exec] Go env not found in your system, proceeding with
>>> installation.
>>>  [exec] Downloading Go 1.23.1...
>>>  [exec] Installing Go 1.23.1...
>>>  [exec] Building the cqlprotodoc...
>>>  [exec] Cloning into 'cassandra-website'...
>>>  [exec] Your branch is up to date with 'origin/trunk'.
>>>  [exec] go: downloading github.com/mvdan/xurls v1.1.0
>>>  [exec] Processing the .spec files...
>>>
>>> I personally consider this extremely dangerous, but also unnecessary. My
>>> current stance is that functionality introducing python3 and go should be
>>> moved to a separate task that only runs on demand / ci / release.  I
>>> welcome convincing arguments that would suggest otherwise.
>>>
>>> If you agree we should not require python and go to run `ant
>>> -Dno-checkstyle=true`, please also write a short message, this will be very
>>> helpful as well.
>>>
>>> Thank you,
>>> --Alex
>>>
>>

Re: [VOTE] Simplifying our release versioning process

[Ekaterina Dimitrova]

I should say that I also haven’t thought of JDK versions when I voted here.
Also, I thought we had separate discussion about them - that we want to
keep up possibly with the last two LTS versions. Currently we do not have
vision on when will be the next release date, so I cannot personally align
JDK LTS versions to our versioning. Also, depends on people availability
and testing resources when and what versions we will maintain our builds
with. (And when and what Cassandra releases we will have, too)

Regarding the - “do not change what we vote for in the middle of the vote”
- I agree, this is not the way to do it. But honestly I did not perceive
this voting as such a case. I also knew about the agreement that any
breaking changes will be discussed on the dev mailing list prior removal
and we try to be backward compatible as much as possible.

On Wed, 23 Apr 2025 at 18:02, Jeremiah Jordan  wrote:

> > The JVM version also isn’t a feature to deprecate, technically.
>
> I agree with this. I think the JVM version the server runs under and how
> we cycle those is a separate discussion from feature deprecation.
>
> There can and has been some overlap there that would need to be handled on
> a case by case basis (when a new JVM removed something that we did not have
> a good way to keep doing without it, talking about you scripting runtime
> based UDFs), but in general I don’t think switching JVMs is the same as
> feature removal/deprecation.
>
> -Jeremiah
>
>
> On Wed, Apr 23, 2025 at 4:48 PM Jordan West  wrote:
>
>> I agree with Jon that I’m now a bit confused on part of what I voted for.
>> It feels like there is more discussion to be had here. Or we need to split
>> it into two votes if we want to make progress on the part where there is
>> consensus and revisit where there is not.
>>
>> Regarding JVM version what I’ve mostly seen as reasons against forcing a
>> JVM upgrade with a C* upgrade is risk tolerance. Folks bit by past upgrades
>> have a tendency to want to limit as many variables as possible. From a
>> technical perspective I’m not sure that’s justified tbh but having been one
>> of the folks wanting to reduce variables and still getting bit by upgrades
>> I understand it. The JVM version also isn’t a feature to deprecate,
>> technically. And having made the decision once to hold off on upgrading the
>> JVM and regretting it I too would like to see the project try to keep pace
>> with JVM releases instead of being on older LTS or unsupported versions.
>>
>> Jordan
>>
>> On Wed, Apr 23, 2025 at 13:49 Jon Haddad  wrote:
>>
>>> >   If 5.0 supports 17, then 7.0 should too, if we are to say we
>>> support 5.0 to 7.0 upgrades.
>>>
>>> I have to disagree with this.  I don't see a good reason have a tight
>>> coupling of JVM versions to C* versions, and I also don't see a good reason
>>> to overlap outside of CI.  Even on CI, the reasoning is a bit weak, Linux
>>> distros have supported multiple JDK versions for at least a decade
>>> (update-java-alternatives on Ubuntu and alternatives on RedHat).
>>>
>>> I've heard several folks explain their reasoning for overlap in JVM
>>> versions, and it just doesn't resonate with me when weighed against the
>>> downsides of being anchored to the limitations imposed by supporting old
>>> JVM versions.
>>>
>>> I don't want this to come back and bite us later - so unless we're
>>> exempting the JVM version from this upgrade requirement, I'm changing my
>>> vote to  -1.
>>>
>>> Furthermore, really shouldn't be changing the terms of the thing we're
>>> voting on mid-vote.  This feels really weird to me.  Anyone who cast a vote
>>> previously may not be keeping up with the ML on a daily basis and it's not
>>> fair to impose changes on them.  People should be aware of what they're
>>> voting for and not be surprised when the VOTE is closed.
>>>
>>> Jon
>>>
>>>
>>>
>>> On Wed, Apr 23, 2025 at 1:04 PM Mick Semb Wever  wrote:
>>>
.

>
> This reads to me that Java 17 would need to be deprecated now,
> continue to be deprecated in 6.0 (at least one major in deprecated), then
> removed in 7.0.
>


 This is technically true.  But I don't think we need to be explicitly
 deprecating jdk versions.  Users are generally aware of Java's LTS cycle,
 and we can document this separately.

 Where we are bound is that our upgrade tests require an overlapping
 common jdk.  So we can only test upgrades that support a common jdk.  And
 🥁  IMHO, we should not be saying we recommend/support upgrades that we
 don't test (regardless if not having broken compatibility means we think
 untested upgrade paths would still work).   If 5.0 supports 17, then 7.0
 should too, if we are to say we support 5.0 to 7.0 upgrades.


>>>

Re: [VOTE] Simplifying our release versioning process

[Joseph Lynch]

Isn't the JDK we build with when publishing to maven somewhat of a public
interface due to cassandra-all library usage? I agree that we probably just
need to clearly document what JVMs we test a release on which is a good
signal for what we think will work at runtime (and this may be a much newer
JVM than we built with).

Apologies I didn't intend to change what we were voting on, I was just
trying to understand if we were voting on the original text or the original
text *plus* the "we don't break things and discuss breakage before breaking
apis" (which I still can't find on the wiki, but I am likely just bad at
search).

I do agree version and feature support is perhaps a separate topic from
killing the minor (which seems unambiguously good).

-Joey


On Wed, Apr 23, 2025 at 7:47 PM Josh McKenzie  wrote:

> Pragmatically, I believe our in-jvm upgrade dtests require the 2 versions
> of C* you're testing to both support running on (and probably right now
> building on) a shared JDK version. So for instance, if we had:
>
> - Release 21.0.0: JDK30, JDK31
> - Release 22.0.0: JDK35, JDK40
>
> We wouldn't be able to test an upgrade from 21 to 22. Arguably we could
> *build* on an older supported version and run both on the newer, but at
> least right now I think that's our restriction. There's tension here if our
> release cadence and LTS JDK's intersect badly, but JDK LTS is infrequent
> enough relative to our releases that I think we're potentially getting
> worked up about a non-issue here.
>
> Since the JDK isn't an API and we've already discussed and have some
> measure of consensus in the past (I thought; haven't dug that up now due to
> shortage of time), I think we can and should formalize that separately from
> this vote thread.
>
> On Wed, Apr 23, 2025, at 6:31 PM, David Capwell wrote:
>
> Also, I thought we had separate discussion about them - that we want to
> keep up possibly with the last two LTS versions.
>
>
> This is what I remember as well.  6.0 would support 17/21 as thats the
> latest, if 7.0 is out before 25, then 7.0 would be 17/21, else it would be
> 21/25
>
> On Apr 23, 2025, at 3:11 PM, Ekaterina Dimitrova 
> wrote:
>
> I should say that I also haven’t thought of JDK versions when I voted
> here. Also, I thought we had separate discussion about them - that we want
> to keep up possibly with the last two LTS versions. Currently we do not
> have vision on when will be the next release date, so I cannot personally
> align JDK LTS versions to our versioning. Also, depends on people
> availability and testing resources when and what versions we will maintain
> our builds with. (And when and what Cassandra releases we will have, too)
>
> Regarding the - “do not change what we vote for in the middle of the vote”
> - I agree, this is not the way to do it. But honestly I did not perceive
> this voting as such a case. I also knew about the agreement that any
> breaking changes will be discussed on the dev mailing list prior removal
> and we try to be backward compatible as much as possible.
>
> On Wed, 23 Apr 2025 at 18:02, Jeremiah Jordan  wrote:
>
> > The JVM version also isn’t a feature to deprecate, technically.
> I agree with this. I think the JVM version the server runs under and how
> we cycle those is a separate discussion from feature deprecation.
>
> There can and has been some overlap there that would need to be handled on
> a case by case basis (when a new JVM removed something that we did not have
> a good way to keep doing without it, talking about you scripting runtime
> based UDFs), but in general I don’t think switching JVMs is the same as
> feature removal/deprecation.
>
> -Jeremiah
>
>
> On Wed, Apr 23, 2025 at 4:48 PM Jordan West  wrote:
>
> I agree with Jon that I’m now a bit confused on part of what I voted for.
> It feels like there is more discussion to be had here. Or we need to split
> it into two votes if we want to make progress on the part where there is
> consensus and revisit where there is not.
>
> Regarding JVM version what I’ve mostly seen as reasons against forcing a
> JVM upgrade with a C* upgrade is risk tolerance. Folks bit by past upgrades
> have a tendency to want to limit as many variables as possible. From a
> technical perspective I’m not sure that’s justified tbh but having been one
> of the folks wanting to reduce variables and still getting bit by upgrades
> I understand it. The JVM version also isn’t a feature to deprecate,
> technically. And having made the decision once to hold off on upgrading the
> JVM and regretting it I too would like to see the project try to keep pace
> with JVM releases instead of being on older LTS or unsupported versions.
>
>
> Jordan
>
> On Wed, Apr 23, 2025 at 13:49 Jon Haddad  wrote:
>
> >   If 5.0 supports 17, then 7.0 should too, if we are to say we support
> 5.0 to 7.0 upgrades.
>
> I have to disagree with this.  I don't see a good reason have a tight
> coupling of JVM versions to C* versions, and I also don't see a g

Re: [VOTE] Simplifying our release versioning process

[C. Scott Andreas]

I propose we:- Exclude JDK support from the subject of this vote.- And start a separate [DISCUSS] and [VOTE] thread to cover JDK/JRE lifecycle.Josh’s proposal that we are voting on does not address JDK versioning, and I don’t interpret the text of the proposal as a referendum on it. Many / most did not seem to have JDK versioning in mind when voting on a policy concerning feature lifecycle and user-visible API surface.I see the point on JDK-as-interface, but I think we can make meaningful forward progress on feature/API lifecycle if we bracket runtime as a separate topic.– ScottOn Apr 23, 2025, at 9:04 PM, Joseph Lynch  wrote:Isn't the JDK we build with when publishing to maven somewhat of a public interface due to cassandra-all library usage? I agree that we probably just need to clearly document what JVMs we test a release on which is a good signal for what we think will work at runtime (and this may be a much newer JVM than we built with).Apologies I didn't intend to change what we were voting on, I was just trying to understand if we were voting on the original text or the original text plus the "we don't break things and discuss breakage before breaking apis" (which I still can't find on the wiki, but I am likely just bad at search).I do agree version and feature support is perhaps a separate topic from killing the minor (which seems unambiguously good).-JoeyOn Wed, Apr 23, 2025 at 7:47 PM Josh McKenzie  wrote:Pragmatically, I believe our in-jvm upgrade dtests require the 2 versions of C* you're testing to both support running on (and probably right now building on) a shared JDK version. So for instance, if we had:- Release 21.0.0: JDK30, JDK31- Release 22.0.0: JDK35, JDK40We wouldn't be able to test an upgrade from 21 to 22. Arguably we could build on an older supported version and run both on the newer, but at least right now I think that's our restriction. There's tension here if our release cadence and LTS JDK's intersect badly, but JDK LTS is infrequent enough relative to our releases that I think we're potentially getting worked up about a non-issue here.Since the JDK isn't an API and we've already discussed and have some measure of consensus in the past (I thought; haven't dug that up now due to shortage of time), I think we can and should formalize that separately from this vote thread.On Wed, Apr 23, 2025, at 6:31 PM, David Capwell wrote:Also, I thought we had separate discussion about them - that we want to keep up possibly with the last two LTS versions.This is what I remember as well.  6.0 would support 17/21 as thats the latest, if 7.0 is out before 25, then 7.0 would be 17/21, else it would be 21/25On Apr 23, 2025, at 3:11 PM, Ekaterina Dimitrova  wrote:I should say that I also haven’t thought of JDK versions when I voted here. Also, I thought we had separate discussion about them - that we want to keep up possibly with the last two LTS versions. Currently we do not have vision on when will be the next release date, so I cannot personally align JDK LTS versions to our versioning. Also, depends on people availability and testing resources when and what versions we will maintain our builds with. (And when and what Cassandra releases we will have, too)Regarding the - “do not change what we vote for in the middle of the vote” - I agree, this is not the way to do it. But honestly I did not perceive this voting as such a case. I also knew about the agreement that any breaking changes will be discussed on the dev mailing list prior removal and we try to be backward compatible as much as possible. On Wed, 23 Apr 2025 at 18:02, Jeremiah Jordan  wrote:> The JVM version also isn’t a feature to deprecate, technically. I agree with this. I think the JVM version the server runs under and how we cycle those is a separate discussion from feature deprecation.There can and has been some overlap there that would need to be handled on a case by case basis (when a new JVM removed something that we did not have a good way to keep doing without it, talking about you scripting runtime based UDFs), but in general I don’t think switching JVMs is the same as feature removal/deprecation.-JeremiahOn Wed, Apr 23, 2025 at 4:48 PM Jordan West  wrote:I agree with Jon that I’m now a bit confused on part of what I voted for. It feels like there is more discussion to be had here. Or we need to split it into two votes if we want to make progress on the part where there is consensus and revisit where there is not. Regarding JVM version what I’ve mostly seen as reasons against forcing a JVM upgrade with a C* upgrade is risk tolerance. Folks bit by past upgrades have a tendency to want to limit as many variables as possible. From a technical perspective I’m not sure that’s justified tbh but having been one of the folks wanting to reduce variables and still getting bit by upgrades I understand it. The JVM version also isn’t a feature to depreca