[VOTE] Simplifying our release versioning process

[Josh McKenzie]

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

Re: Constraint's "not null" alignment with transactions and their simplification

[Jon Haddad]

Maybe I misremember the convo, but I thought both of these was possible:

CREATE table test ( id int primary key
val int check val > 0,
val2 int
)

INSERT INTO test (id) values (1);  ## inserts with empty val
UPDATE test set val2 = 1;  ## inserts with empty val


Are you saying supplying val is required in both cases?

In the second case, does a user always have to overwrite the field?

Jon


On Wed, Apr 16, 2025 at 11:43 PM Štefan Miklošovič 
wrote:

> _A bigger issue, is the actual behavior, in that you can say NOT NULL and
> still easily get null values by not supplying the value.  The constraint is
> more of a weakly applied suggestion._
>
> This is not true. You can not really put there null. See other discussion
> about this behaviour on ML.
>
> On Wed, Apr 16, 2025 at 6:36 PM Jon Haddad 
> wrote:
>
>> I think the world is fairly used to NOT NULL in line with the type.  I
>> don't see much value in paving our own path for things that are established
>> norms.  Let's not reinvent wheels that don't need reinventing.
>>
>> I also think it's fine if the generated CQL from describe doesn't match
>> the user's input.  We already do this with all the table level fields that
>> get added.  I'm not sure why we should care if a user drifts away from not
>> null either.  I think these are pretty irrelevant details in the grand
>> scheme of things.
>>
>> A bigger issue, is the actual behavior, in that you can say NOT NULL and
>> still easily get null values by not supplying the value.  The constraint is
>> more of a weakly applied suggestion.  I'm expecting a bit of confusion
>> around this.  I wonder if it makes sense to not allow prepared INSERT
>> statements that don't contain the field if it's null constrained, although
>> it doesn't really help us in the case of an upsert.  It does narrow the
>> edge case a bit, which could be argued is good or bad depending on
>> someone's mood.
>>
>> I think it should be made clear that what we're really giving the user
>> when we say `value check not null` is this:
>>
>> INSERT INTO blah (id, value) VALUES(?, ? not null);
>>
>> Does accord change the behavior of INSERT to actually mean INSERT and not
>> UPSERT, or do you still have to specify IF NOT EXISTS?
>>
>> Jon
>>
>>
>>
>> On Wed, Apr 16, 2025 at 12:50 AM Štefan Miklošovič <
>> smikloso...@apache.org> wrote:
>>
>>> Maybe I am too naive and idealist but I can see a world where, even we
>>> enable them to do it like "val int not null", after they describe a table
>>> and they see "val int check not null" they start to use the latter form
>>> because they would be tired of switching two forms in their head all the
>>> time when they see that all other checks they want to specify have to be
>>> specified in "val int check ..." form. They might actually start to
>>> appreciate the unified fashion of it and they will themselves drift away
>>> from "val int not null" eventually. I would :D.
>>>
>>> As we are among leaders in NoSQL databases we have also a great leverage
>>> over how stuff is going to be used and we can actively form this space. We
>>> do not need to just follow.
>>>
>>> I am open to supporting specifying "val int not null" _together with_
>>> "val int check not null" form. Not _exclusively_ SQL syntax only. This
>>> syntax sugar can go in anytime and it is more or less purely "additive".
>>> Even if a user specifies it like "val int not null" it will be internally
>>> stored as "val int check not null" to be consistent with how it is going to
>>> be represented internally with all other checks. NOT NULL will ultimately
>>> be a check as any other we have, it is just how it might be defined on the
>>> CQL level which we are arguing about here.
>>>
>>> On Wed, Apr 16, 2025 at 12:56 AM Patrick McFadin 
>>> wrote:
>>>
 I may be to blame for some of that energy. :D

 No, we don't have consensus on that direction, but I think we will
 eventually. CQL started out as a subset of SQL but has drifted because
 features get added async and there just hasn't been any formal standard or
 road map or lofty goal. We've been laying out track in front of us as we go
 along. A couple of years ago, I had a conversation at ApacheCon, and it
 started slowly rattling around my brain that the developer experience
 destination is regression to a mean and not charting a bold new path.
 Everything else in Cassandra was already charting plenty of new paths, but
 if we give users a calm, familiar API, that feels like a winner. SQL is
 already a standard and could be our roadmap.

 With all that, I've been getting back into the data modeling game and
 seeing how a slightly different syntax can lead to angry users. In
 conversations with users, the idea of being SQL compatible in syntax
 (features can come whenever) is highly appealing. In reality, we are
 talking about CQL4, but why create tech debt for later if we design
 features now? My dream would be to ha

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

[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

[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

[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: CEP-15 Update

[Jordan West]

Congrats all! My previous reservations (that have been addressed) aside,
this is an amazing milestone. Awesome, awesome work!

Jordan

On Thu, Apr 17, 2025 at 15:07 David Capwell  wrote:

> I have merged cep-15-accord into trunk.  If you experience any issues
> please reach out to me
>
>
> On Apr 17, 2025, at 12:55 AM, Benedict Elliott Smith 
> wrote:
>
> Final update: David has completed a second rebase after we reached parity
> with trunk on our CI, and has confirmed tests remain stable. So I expect
> CEP-15 to merge to trunk sometime today.
>
> No doubt there will be some unexpected disruption to others after a patch
> like this lands. Reach out via slack if you have any trouble.
>
> On 16 Mar 2025, at 10:44, Benedict Elliott Smith 
> wrote:
>
> Hi everyone,
>
> To update you: the last patches we considered blockers have landed in the
> cep-15-accord branch. Caleb has now started rebasing the branch onto trunk.
> I expect there will be a few failing tests still to resolve at that point,
> but once they have been squashed we will proceed with the merge.
>
> There remains more work to do before release, and I will publish a
> detailed roadmap to Jira when I’m back in a couple of weeks.
>
>
> On 11 Mar 2025, at 20:12, Nate McCall  wrote:
>
> It sounds like we are all pretty interested in seeing this feature land
> and the branch maintenance is causing overhead that could be spent on
> finalisation. +1 on merging, particularly given the feature flag work.
>
> Once more unto the breach 💪
>
> On Fri, 7 Mar 2025 at 6:56 PM, Benedict  wrote:
>
>> There are essentially three possible timelines to choose from here:
>>
>> 1) We agree in the next few days to merge to trunk. We will then
>> prioritise rebasing onto trunk and resolving any pre-merge items starting
>> next week.
>> 2) There’s some more debate and agreement to merge to trunk in a week or
>> two. In the meantime we will shift to internal-first development but we’ll
>> likely prioritise the above work as soon as we can, which may be in a few
>> weeks, so we can shift to trunk first development.
>> 3) We don’t agree to merge accord anytime soon, so we shift to
>> internal-first development for the time being. I’m not sure when we will
>> prioritise any of the above.
>>
>> Our resources are finite and we’ve exhausted them (literally), so it’s
>> pretty much pick one of the above. I don’t really mind which you pick, but
>> I won’t personally be prioritising merge after this third attempt.
>>
>> On 6 Mar 2025, at 22:01, Jon Haddad  wrote:
>>
>> 
>>
>> Hmm... I took a look at the cep-15-accord branch in GitHub, it looks like
>> it's several hundred commits behind trunk.  Since you'll need to rebase
>> again before merge *anyways*, would it make sense to do it once more, and I
>> can publish easy-cass-lab with the latest branch?  If folks have concerns,
>> it's easy to fire up a cluster (I do it constantly) and try it out.
>>
>> I think if we were to do this, out of consideration we should time box
>> the amount of time for an evaluation and unless someone raises an
>> objection, consider lazy consensus achieved.
>>
>> Jon
>>
>>
>>
>> On Thu, Mar 6, 2025 at 12:46 PM Benedict Elliott Smith <
>> bened...@apache.org> wrote:
>>
>>> Because we want to validate against the latest code in trunk, else we
>>> are validating stale behaviours. The cost of rebasing is high, so we do not
>>> do it frequently. That means we will likely stop developing OSS-first, as
>>> the focus will have to move to our internal branch that satisfies these
>>> criteria.
>>>
>>> Exactly what this might be for upstreaming I cannot say. Personally, I
>>> aim to work exclusively on the branch we are stabilising. If that is not
>>> trunk, the latency for my contributions being made public might be high, as
>>> I have a huge imbalance of over-investment to recoup, and anything
>>> unnecessary will be deferred.
>>>
>>> Since the feature is disabled, and the code is almost entirely isolated,
>>> I cannot imagine the cost to the community to removing this work would be
>>> very high. But, I do not intend to argue Accord’s case here. I will let you
>>> all decide.
>>>
>>> Please decide soon though, as it shapes our work planning. The positive
>>> reception so far had lead me to consider prioritising a move to trunk-first
>>> development within the next week or two, and the associated work that
>>> entails. However, if that was optimistic we will have to shift our plans.
>>>
>>>
>>>
>>> On 6 Mar 2025, at 20:16, Jordan West  wrote:
>>>
>>> The work and effort in accord has been amazing. And I’m sure it sets a
>>> new standard for code quality and correctness testing which I’m also
>>> entirely behind. I also trust the folks working on it want to take it to
>>> the a fully production ready solution. But I’m worried about circumstances
>>> out of our control leaving us with a very complex feature that isn’t
>>> complete.
>>>
>>> I do have some questions. Could folks help me better understand why
>>> tes

Re: [DISCUSS] How we version our releases

[David Capwell]

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

My understanding is things are not different than before, we just don’t do 
minors; which is what caused more confusion around this topic.

Lets say we deprecate something in 6.0.0 (trunk), then 7.x must keep the 
support, but 8.0.0 is free to delete it.

Where the current process gets unclear is when you deprecate something in 4.1, 
can you remove it in 6.0?  

One thing that would be great to be super clear about, if a patch release 
deprecates a feature, does that act as if the next major deprecated it, or the 
current major?   Aka 6.0.1 deprecates something can we delete it in 8.0.0 or is 
it only free to delete in 9.0.0?

Also, I know we don’t plan to have 3 places, I just am using it out of habit 
and to be clear with the current model =D

> On Apr 17, 2025, at 10:30 AM, Yifan Cai  wrote:
> 
> Just realized that the other thread is for [vote]. Posting my question here 
> instead...
> 
> 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?
> 
> 
> On Wed, Apr 16, 2025 at 5:15 AM Josh McKenzie  > wrote:
>>> 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
>> Does the clarification in the earlier thread help shift your perspective / 
>> address your concerns here David?
>> 
>> Will leave this thread for another 24 hours to see if there's any other 
>> concerns and call a vote if not.
>> 
>> Thanks everyone for the engagement.
>> 
>> On Fri, Apr 11, 2025, at 11:22 AM, Josh McKenzie wrote:
 So we avoid 6.1, 7.2, etc?  Does this imply that each release is allowed 
 to make breaking changes (assuming they followed the “correct” deprecation 
 process)? 
>>> Yes and no.
>>> 
>>> A release can't make a breaking change relative to the immediately 
>>> preceding release, if something has been deprecated.
>>> 
>>> A release can make a breaking change from another actively supported 
>>> release if it's not an adjacent release and the feature was signaled as 
>>> deprecated in the interim release.
>>> 
>>> On Fri, Apr 11, 2025, at 10:39 AM, Jon Haddad wrote:
 +1.
 
 It's the proper signal to the community.  A .1 release could still be done 
 as an exception, but I have a hard time thinking of a case other than 
 supporting a newer JDK without any other changes. 
 
 On Fri, Apr 11, 2025 at 7:19 AM Jeremiah Jordan >>> > wrote:
 +1 from me.
 No more wondering what the next version number will be.
 No more wondering what version I can upgrade from to use the new release.
 
 -Jeremiah
 
 On Apr 10, 2025 at 3:54:13 PM, Josh McKenzie >>> > wrote:
> 
> This came up in the thread from Jon on "5.1 should be 6.0".
> 
> I think it's important that our release versioning is clear and simple. 
> The current status quo of:
> - Any .MINOR to next MAJOR is supported  
> - Any .MAJOR to next MAJOR is supported  
> - We reserve .MAJOR for API breaking changes
> - except for when we get excited about a feature and want to .MAJOR 
> to signal that
> - or we change JDK's and need to signal that
> - or any of another slew of caveats that require digging into 
> NEWS.txt to see what the hell we're up to. :D
> - And all of our CI pain that ensues from the above
> 
> In my opinion the above is overly complex and could use simplification. I 
> also believe us re-litigating this on every release is a waste of time 
> and energy that could better be spent elsewhere on the project or in 
> life. It's also a signal about how confusing our release versioning has 
> been for the community.
> 
> Let's leave aside the decision about whether we scope releases based on 
> time or based on features; let's keep this to the discussion about how we 
> version our releases.
> 
> So here's what I'm thinking: a new release strategy that doesn't use 
> .MINOR of semver. Goals:
> - Simplify versioning for end users
> - Provide clearer contracts for users as to what they can expect in 
> releases
> - Sim

Re: CEP-15 Update

[Benedict Elliott Smith]

Final update: David has completed a second rebase after we reached parity with 
trunk on our CI, and has confirmed tests remain stable. So I expect CEP-15 to 
merge to trunk sometime today.

No doubt there will be some unexpected disruption to others after a patch like 
this lands. Reach out via slack if you have any trouble.

> On 16 Mar 2025, at 10:44, Benedict Elliott Smith  wrote:
> 
> Hi everyone,
> 
> To update you: the last patches we considered blockers have landed in the 
> cep-15-accord branch. Caleb has now started rebasing the branch onto trunk. I 
> expect there will be a few failing tests still to resolve at that point, but 
> once they have been squashed we will proceed with the merge.
> 
> There remains more work to do before release, and I will publish a detailed 
> roadmap to Jira when I’m back in a couple of weeks. 
> 
> 
>> On 11 Mar 2025, at 20:12, Nate McCall  wrote:
>> 
>> It sounds like we are all pretty interested in seeing this feature land and 
>> the branch maintenance is causing overhead that could be spent on 
>> finalisation. +1 on merging, particularly given the feature flag work. 
>> 
>> Once more unto the breach 💪
>> 
>> On Fri, 7 Mar 2025 at 6:56 PM, Benedict > > wrote:
>>> There are essentially three possible timelines to choose from here: 
>>> 
>>> 1) We agree in the next few days to merge to trunk. We will then prioritise 
>>> rebasing onto trunk and resolving any pre-merge items starting next week.
>>> 2) There’s some more debate and agreement to merge to trunk in a week or 
>>> two. In the meantime we will shift to internal-first development but we’ll 
>>> likely prioritise the above work as soon as we can, which may be in a few 
>>> weeks, so we can shift to trunk first development.
>>> 3) We don’t agree to merge accord anytime soon, so we shift to 
>>> internal-first development for the time being. I’m not sure when we will 
>>> prioritise any of the above.
>>> 
>>> Our resources are finite and we’ve exhausted them (literally), so it’s 
>>> pretty much pick one of the above. I don’t really mind which you pick, but 
>>> I won’t personally be prioritising merge after this third attempt.
>>> 
 On 6 Mar 2025, at 22:01, Jon Haddad >>> > wrote:
 
 
>>> 
 Hmm... I took a look at the cep-15-accord branch in GitHub, it looks like 
 it's several hundred commits behind trunk.  Since you'll need to rebase 
 again before merge *anyways*, would it make sense to do it once more, and 
 I can publish easy-cass-lab with the latest branch?  If folks have 
 concerns, it's easy to fire up a cluster (I do it constantly) and try it 
 out.
 
 I think if we were to do this, out of consideration we should time box the 
 amount of time for an evaluation and unless someone raises an objection, 
 consider lazy consensus achieved.
 
 Jon
 
 
 
 On Thu, Mar 6, 2025 at 12:46 PM Benedict Elliott Smith 
 mailto:bened...@apache.org>> wrote:
> Because we want to validate against the latest code in trunk, else we are 
> validating stale behaviours. The cost of rebasing is high, so we do not 
> do it frequently. That means we will likely stop developing OSS-first, as 
> the focus will have to move to our internal branch that satisfies these 
> criteria.
> 
> Exactly what this might be for upstreaming I cannot say. Personally, I 
> aim to work exclusively on the branch we are stabilising. If that is not 
> trunk, the latency for my contributions being made public might be high, 
> as I have a huge imbalance of over-investment to recoup, and anything 
> unnecessary will be deferred.
> 
> Since the feature is disabled, and the code is almost entirely isolated, 
> I cannot imagine the cost to the community to removing this work would be 
> very high. But, I do not intend to argue Accord’s case here. I will let 
> you all decide.
> 
> Please decide soon though, as it shapes our work planning. The positive 
> reception so far had lead me to consider prioritising a move to 
> trunk-first development within the next week or two, and the associated 
> work that entails. However, if that was optimistic we will have to shift 
> our plans.
> 
> 
> 
>> On 6 Mar 2025, at 20:16, Jordan West > > wrote:
>> 
>> The work and effort in accord has been amazing. And I’m sure it sets a 
>> new standard for code quality and correctness testing which I’m also 
>> entirely behind. I also trust the folks working on it want to take it to 
>> the a fully production ready solution. But I’m worried about 
>> circumstances out of our control leaving us with a very complex feature 
>> that isn’t complete. 
>> 
>> I do have some questions. Could folks help me better understand why 
>> testing real workloads necessitates a merg

Re: [DISCUSS] How we version our releases

[Yifan Cai]

Just realized that the other thread is for [vote]. Posting my question here
instead...

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?


On Wed, Apr 16, 2025 at 5:15 AM Josh McKenzie  wrote:

> 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
>
> Does the clarification in the earlier thread help shift your perspective /
> address your concerns here David?
>
> Will leave this thread for another 24 hours to see if there's any other
> concerns and call a vote if not.
>
> Thanks everyone for the engagement.
>
> On Fri, Apr 11, 2025, at 11:22 AM, Josh McKenzie wrote:
>
> So we avoid 6.1, 7.2, etc?  Does this imply that each release is allowed
> to make breaking changes (assuming they followed the “correct” deprecation
> process)?
>
> Yes and no.
>
> A release can't make a breaking change *relative to the immediately
> preceding release*, if something has been deprecated.
>
> A release *can* make a breaking change *from another actively supported
> release* if it's not an adjacent release and the feature was signaled as
> deprecated in the interim release.
>
> On Fri, Apr 11, 2025, at 10:39 AM, Jon Haddad wrote:
>
> +1.
>
> It's the proper signal to the community.  A .1 release could still be done
> as an exception, but I have a hard time thinking of a case other than
> supporting a newer JDK without any other changes.
>
> On Fri, Apr 11, 2025 at 7:19 AM Jeremiah Jordan 
> wrote:
>
> +1 from me.
> No more wondering what the next version number will be.
> No more wondering what version I can upgrade from to use the new release.
>
> -Jeremiah
>
> On Apr 10, 2025 at 3:54:13 PM, Josh McKenzie  wrote:
>
>
> This came up in the thread from Jon on "5.1 should be 6.0".
>
> I think it's important that our release versioning is clear and simple.
> The current status quo of:
> - Any .MINOR to next MAJOR is supported
> - Any .MAJOR to next MAJOR is supported
> - We reserve .MAJOR for API breaking changes
> - except for when we get excited about a feature and want to .MAJOR to
> signal that
> - or we change JDK's and need to signal that
> - or any of another slew of caveats that require digging into NEWS.txt
> to see what the hell we're up to. :D
> - And all of our CI pain that ensues from the above
>
> In my opinion the above is overly complex and could use simplification. I
> also believe us re-litigating this on every release is a waste of time and
> energy that could better be spent elsewhere on the project or in life. It's
> also a signal about how confusing our release versioning has been for the
> community.
>
> Let's leave aside the decision about whether we scope releases based on
> time or based on features; let's keep this to the discussion about how we
> version our releases.
>
> So here's what I'm thinking: a new release strategy that doesn't use
> .MINOR of semver. Goals:
> - Simplify versioning for end users
> - Provide clearer contracts for users as to what they can expect in
> releases
> - Simplify support for us (CI, merges, etc)
> - Clarify our public API deprecation process
>
> Structure / heuristic:
> - Online upgrades are supported for all GA supported releases at time of
> new .MAJOR
> - T-1 releases are guaranteed API compatible
> - We use a deprecate-then-remove strategy for API breaking changes
>
> This would translate into the following for our upcoming releases
> (assuming we stick with 3 supported majors at any given time):
> 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
>
> So: what do we think?
>
>
>
>

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

[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

[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

[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: CEP-15 Update

[David Capwell]

I have merged cep-15-accord into trunk.  If you experience any issues please 
reach out to me

> On Apr 17, 2025, at 12:55 AM, Benedict Elliott Smith  
> wrote:
> 
> Final update: David has completed a second rebase after we reached parity 
> with trunk on our CI, and has confirmed tests remain stable. So I expect 
> CEP-15 to merge to trunk sometime today.
> 
> No doubt there will be some unexpected disruption to others after a patch 
> like this lands. Reach out via slack if you have any trouble.
> 
>> On 16 Mar 2025, at 10:44, Benedict Elliott Smith  wrote:
>> 
>> Hi everyone,
>> 
>> To update you: the last patches we considered blockers have landed in the 
>> cep-15-accord branch. Caleb has now started rebasing the branch onto trunk. 
>> I expect there will be a few failing tests still to resolve at that point, 
>> but once they have been squashed we will proceed with the merge.
>> 
>> There remains more work to do before release, and I will publish a detailed 
>> roadmap to Jira when I’m back in a couple of weeks. 
>> 
>> 
>>> On 11 Mar 2025, at 20:12, Nate McCall  wrote:
>>> 
>>> It sounds like we are all pretty interested in seeing this feature land and 
>>> the branch maintenance is causing overhead that could be spent on 
>>> finalisation. +1 on merging, particularly given the feature flag work. 
>>> 
>>> Once more unto the breach 💪
>>> 
>>> On Fri, 7 Mar 2025 at 6:56 PM, Benedict >> > wrote:
 There are essentially three possible timelines to choose from here: 
 
 1) We agree in the next few days to merge to trunk. We will then 
 prioritise rebasing onto trunk and resolving any pre-merge items starting 
 next week.
 2) There’s some more debate and agreement to merge to trunk in a week or 
 two. In the meantime we will shift to internal-first development but we’ll 
 likely prioritise the above work as soon as we can, which may be in a few 
 weeks, so we can shift to trunk first development.
 3) We don’t agree to merge accord anytime soon, so we shift to 
 internal-first development for the time being. I’m not sure when we will 
 prioritise any of the above.
 
 Our resources are finite and we’ve exhausted them (literally), so it’s 
 pretty much pick one of the above. I don’t really mind which you pick, but 
 I won’t personally be prioritising merge after this third attempt.
 
> On 6 Mar 2025, at 22:01, Jon Haddad  > wrote:
> 
> 
 
> Hmm... I took a look at the cep-15-accord branch in GitHub, it looks like 
> it's several hundred commits behind trunk.  Since you'll need to rebase 
> again before merge *anyways*, would it make sense to do it once more, and 
> I can publish easy-cass-lab with the latest branch?  If folks have 
> concerns, it's easy to fire up a cluster (I do it constantly) and try it 
> out.
> 
> I think if we were to do this, out of consideration we should time box 
> the amount of time for an evaluation and unless someone raises an 
> objection, consider lazy consensus achieved.
> 
> Jon
> 
> 
> 
> On Thu, Mar 6, 2025 at 12:46 PM Benedict Elliott Smith 
> mailto:bened...@apache.org>> wrote:
>> Because we want to validate against the latest code in trunk, else we 
>> are validating stale behaviours. The cost of rebasing is high, so we do 
>> not do it frequently. That means we will likely stop developing 
>> OSS-first, as the focus will have to move to our internal branch that 
>> satisfies these criteria.
>> 
>> Exactly what this might be for upstreaming I cannot say. Personally, I 
>> aim to work exclusively on the branch we are stabilising. If that is not 
>> trunk, the latency for my contributions being made public might be high, 
>> as I have a huge imbalance of over-investment to recoup, and anything 
>> unnecessary will be deferred.
>> 
>> Since the feature is disabled, and the code is almost entirely isolated, 
>> I cannot imagine the cost to the community to removing this work would 
>> be very high. But, I do not intend to argue Accord’s case here. I will 
>> let you all decide.
>> 
>> Please decide soon though, as it shapes our work planning. The positive 
>> reception so far had lead me to consider prioritising a move to 
>> trunk-first development within the next week or two, and the associated 
>> work that entails. However, if that was optimistic we will have to shift 
>> our plans.
>> 
>> 
>> 
>>> On 6 Mar 2025, at 20:16, Jordan West >> > wrote:
>>> 
>>> The work and effort in accord has been amazing. And I’m sure it sets a 
>>> new standard for code quality and correctness testing which I’m also 
>>> entirely behind. I also trust the folks working on it want to take it 
>>> to the a fully production read