Re: [VOTE] Simplifying our release versioning process

[Josh McKenzie]

To close the loop here, I've updated our "Patching, release versioning, and LTS 
releases 
"
 wiki article with the agreed upon text here. I added the following 
clarification from the consensus on the prior ML thread:
> We strive for a "never deprecate or remove" approach. Any deprecation or 
> removal needs a dev ML [DISCUSS] thread with clear consensus.

Will see if I can't dig up the consensus on "never deprecate" and update the 
wiki w/that if it's clear, and hope to get a "how we do JDK support" [DISCUSS] 
thread going later this week.

On Fri, Apr 25, 2025, at 5:03 PM, Jordan West wrote:
> On Wed, Apr 23, 2025 at 21:04 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).
>> 
> 
> For better or worse the community has largely treated cassandra-all use 
> (outside of official projects like cassandra-analytics) as “at your own 
> risk”. 
> 
>> 
>> 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 a

Re: [VOTE] Simplifying our release versioning process

[Jordan West]

On Wed, Apr 23, 2025 at 21:04 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).
>

For better or worse the community has largely treated cassandra-all use
(outside of official projects like cassandra-analytics) as “at your own
risk”.


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

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

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

[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: [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

[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.
>>>
>>>
>>

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

[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: [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

[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.

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

[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: [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: [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: [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

[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: [VOTE] Simplifying our release versioning process

[Joseph Lynch]

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 <
>>> e.dimitr...@gmail.com> 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: [VOTE] Simplifying our release versioning process

[Patrick McFadin]

+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 <
>> e.dimitr...@gmail.com> 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: [VOTE] Simplifying our release versioning process

[Dmitry Konstantinov]

+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: [VOTE] Simplifying our release versioning process

[Caleb Rackliffe]

+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

[Ekaterina Dimitrova]

+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

[Sam Tunnicliffe]

+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

[Aleksey Yeshchenko]

+1

> On 22 Apr 2025, at 10:33, Sylvain Lebresne  wrote:
> 
> +1
> --
> Sylvain
> 
> 
> On Tue, Apr 22, 2025 at 10:47 AM Maxim Muzafarov  > wrote:
>> Also +1
>> 
>> On Tue, 22 Apr 2025 at 07:57, guo Maxwell > > wrote:
>> >>
>> >> We have already agreed some time ago that any incompatible API change 
>> >> requires a DISCUSS thread. I’m fairly sure it’s documented on the wiki.
>> >
>> >
>> > Yes, I remembered that we already have a thread to reach consensus on this.
>> >
>> > +1 on this vote.
>> >
>> > Mick Semb Wever mailto:m...@apache.org>> 于2025年4月22日周二 
>> > 13:35写道：
>> >>
>> >>
>> >> .
>> >>
>> >>
>> >>
>> >>>
>> >>> I'll plan to leave the vote open until we hit enough participation to 
>> >>> pass or fail it up to probably a couple weeks.
>> >>
>> >>
>> >>
>> >> +1
>> >>

Re: [VOTE] Simplifying our release versioning process

[Sylvain Lebresne]

+1
--
Sylvain


On Tue, Apr 22, 2025 at 10:47 AM Maxim Muzafarov  wrote:

> Also +1
>
> On Tue, 22 Apr 2025 at 07:57, guo Maxwell  wrote:
> >>
> >> We have already agreed some time ago that any incompatible API change
> requires a DISCUSS thread. I’m fairly sure it’s documented on the wiki.
> >
> >
> > Yes, I remembered that we already have a thread to reach consensus on
> this.
> >
> > +1 on this vote.
> >
> > Mick Semb Wever  于2025年4月22日周二 13:35写道：
> >>
> >>
> >> .
> >>
> >>
> >>
> >>>
> >>> I'll plan to leave the vote open until we hit enough participation to
> pass or fail it up to probably a couple weeks.
> >>
> >>
> >>
> >> +1
> >>
>

Re: [VOTE] Simplifying our release versioning process

[Maxim Muzafarov]

Also +1

On Tue, 22 Apr 2025 at 07:57, guo Maxwell  wrote:
>>
>> We have already agreed some time ago that any incompatible API change 
>> requires a DISCUSS thread. I’m fairly sure it’s documented on the wiki.
>
>
> Yes, I remembered that we already have a thread to reach consensus on this.
>
> +1 on this vote.
>
> Mick Semb Wever  于2025年4月22日周二 13:35写道：
>>
>>
>> .
>>
>>
>>
>>>
>>> I'll plan to leave the vote open until we hit enough participation to pass 
>>> or fail it up to probably a couple weeks.
>>
>>
>>
>> +1
>>

Re: [VOTE] Simplifying our release versioning process

[guo Maxwell]

>
> We have already agreed some time ago that any incompatible API change
> requires a DISCUSS thread. I’m fairly sure it’s documented on the wiki.


Yes, I remembered that we already have a thread to reach consensus on this.

+1 on this vote.

Mick Semb Wever  于2025年4月22日周二 13:35写道：

>
> .
>
>
>
>
>> I'll plan to leave the vote open until we hit enough participation to
>> pass or fail it up to probably a couple weeks.
>>
>
>
> +1
>
>

Re: [VOTE] Simplifying our release versioning process

[Mick Semb Wever]

.




> I'll plan to leave the vote open until we hit enough participation to pass
> or fail it up to probably a couple weeks.
>


+1

Re: [VOTE] Simplifying our release versioning process

[Josh McKenzie]

> I'd like to maintain a *very* high bar for user API-breaking changes – much 
> higher than "our rules allow us to"
I don't know if we've formalized this (or even need to; may be obvious?), but 
having a bar of "[DISCUSS] thread on dev ML with clear consensus" seems 
reasonable for user API-breaking changes. Or additions for that matter (I 
believe we already agreed on the latter).

On Thu, Apr 17, 2025, at 5:38 PM, C. Scott Andreas wrote:
> +1
> 
> To the point on breaking changes and deprecations, I'd like to maintain a 
> *very* high bar for user API-breaking changes – much higher than "our rules 
> allow us to". Any time we break users, the project loses release uptake and 
> creates friction for the community.
> 
> – Scott
> 
>> On Apr 17, 2025, at 2:32 PM, Nate McCall  wrote:
>> 
>> 
>> +1
>> 
>> On Fri, 18 Apr 2025 at 3:59 AM, Josh McKenzie  wrote:
>>> __
>>> [DISCUSS] thread: 
>>> https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq
>>> 
>>> The proposed new versioning mechanism:
>>>  1. We no longer use semver .MINOR
>>>  2. Online upgrades are supported for all GA supported releases at time of 
>>> new .MAJOR
>>>  3. T-1 releases are guaranteed API compatible for non-deprecated features
>>>  4. 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

[Benedict]

+1We have already agreed some time ago that any incompatible API change requires a DISCUSS thread. I’m fairly sure it’s documented on the wiki.I agree with Scott: our norm should be NOT breaking things. There should be strong justification in terms of either development friction or an unsafe or poorly supported (first or third party) feature to justify breaking an API. I’d be happy to strengthen our guidance on this to facilitate future DISCUSS threads.On 18 Apr 2025, at 13:44, Josh McKenzie  wrote:I'd like to maintain a *very* high bar for user API-breaking changes – much higher than "our rules allow us to"I don't know if we've formalized this (or even need to; may be obvious?), but having a bar of "[DISCUSS] thread on dev ML with clear consensus" seems reasonable for user API-breaking changes. Or additions for that matter (I believe we already agreed on the latter).On Thu, Apr 17, 2025, at 5:38 PM, C. Scott Andreas wrote:+1To the point on breaking changes and deprecations, I'd like to maintain a *very* high bar for user API-breaking changes – much higher than "our rules allow us to". Any time we break users, the project loses release uptake and creates friction for the community.– ScottOn Apr 17, 2025, at 2:32 PM, Nate McCall  wrote:+1On Fri, 18 Apr 2025 at 3:59 AM, Josh McKenzie  wrote:[DISCUSS] thread: https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lqThe proposed new versioning mechanism:We no longer use semver .MINOROnline upgrades are supported for all GA supported releases at time of new .MAJORT-1 releases are guaranteed API compatible for non-deprecated featuresWe 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.07.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.08.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.0David 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 thisEach 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

[Nate McCall]

+1

On Fri, 18 Apr 2025 at 3:59 AM, Josh McKenzie  wrote:

> [DISCUSS] thread:
> https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq
>
> The proposed new versioning mechanism:
>
>1. We no longer use semver .MINOR
>2. Online upgrades are supported for all GA supported releases at time
>of new .MAJOR
>3. T-1 releases are guaranteed API compatible for non-deprecated
>features
>4. 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

[C. Scott Andreas]

+1 To the point on breaking changes and deprecations, I'd like to maintain a *very* high bar for user 
API-breaking changes – much higher than "our rules allow us to". Any time we break users, 
the project loses release uptake and creates friction for the community. – Scott On Apr 17, 2025, at 
2:32 PM, Nate McCall  wrote: +1 On Fri, 18 Apr 2025 at 3:59 AM, Josh 
McKenzie < jmcken...@apache.org > 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

[Jordan West]

+1

On Thu, Apr 17, 2025 at 12:14 Jeremiah Jordan  wrote:

> +1
>
> On Apr 17, 2025 at 10:58:24 AM, Josh McKenzie 
> wrote:
>
>> [DISCUSS] thread:
>> https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq
>>
>> The proposed new versioning mechanism:
>>
>>1. We no longer use semver .MINOR
>>2. Online upgrades are supported for all GA supported releases at
>>time of new .MAJOR
>>3. T-1 releases are guaranteed API compatible for non-deprecated
>>features
>>4. 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

[Jeremiah Jordan]

 +1

On Apr 17, 2025 at 10:58:24 AM, Josh McKenzie  wrote:

> [DISCUSS] thread:
> https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq
>
> The proposed new versioning mechanism:
>
>1. We no longer use semver .MINOR
>2. Online upgrades are supported for all GA supported releases at time
>of new .MAJOR
>3. T-1 releases are guaranteed API compatible for non-deprecated
>features
>4. 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

[Yifan Cai]

I would like to get a better understanding of "but only for features that
have already been deprecated for one major release cycle."

Does it mean that one has to flag a feature as deprecated in the unreleased
version N, wait until when N is released (deprecating for one major cycle),
and then finally make the breaking change in N + 1?

Similarly, for a released version, say M (where trunk is at N), should the
author patch M to mark the feature as deprecated, and wait until N is
released (deprecating for one major release cycle), and introduce the
breaking in N + 1?

It would be nice to have examples to clarify the deprecation/breaking
change policy. The examples on version bumping are helpful.

- Yifan

On Thu, Apr 17, 2025 at 10:16 AM Brandon Williams  wrote:

> +1
>
> Kind Regards,
> Brandon
>
> On Thu, Apr 17, 2025 at 10:59 AM 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

[Brandon Williams]

+1

Kind Regards,
Brandon

On Thu, Apr 17, 2025 at 10:59 AM 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

[David Capwell]

+1

> On Apr 17, 2025, at 9:22 AM, Jon Haddad  wrote:
> 
> +1
> 
> On Thu, Apr 17, 2025 at 9:15 AM Josh McKenzie  > wrote:
>> +1
>> 
>> On Thu, Apr 17, 2025, at 11:58 AM, 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

[Jon Haddad]

+1

On Thu, Apr 17, 2025 at 9:15 AM Josh McKenzie  wrote:

> +1
>
> On Thu, Apr 17, 2025, at 11:58 AM, Josh McKenzie wrote:
>
> [DISCUSS] thread:
> https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq
>
> The proposed new versioning mechanism:
>
>1. We no longer use semver .MINOR
>2. Online upgrades are supported for all GA supported releases at time
>of new .MAJOR
>3. T-1 releases are guaranteed API compatible for non-deprecated
>features
>4. 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

[Josh McKenzie]

+1

On Thu, Apr 17, 2025, at 11:58 AM, Josh McKenzie wrote:
> [DISCUSS] thread: 
> https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq
> 
> The proposed new versioning mechanism:
>  1. We no longer use semver .MINOR
>  2. Online upgrades are supported for all GA supported releases at time of 
> new .MAJOR
>  3. T-1 releases are guaranteed API compatible for non-deprecated features
>  4. 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.