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

[Štefan Miklošovič]

Recently, David Capwell was commenting on constraints in one of Slack
threads (1) in dev channel and he suggested that the current form of "not
null" constraint we have right now in place, e.g like this

create table ks.tb (id int primary key, val int check not_null(val));

could be instead of that form used like this:

create table ks.tb (id int primary key, val int check not null);

That is - without the name of a column in the constraint's argument. The
reasoning behind that was that it is not only easier to read but there is
also this concept in transactions (cep-15) where there is also "not null"
used in some fashion and it would be nice if this was aligned so a user
does not encounter two usages of "not null"-s which are written down
differently, syntax-wise.

Could the usage of "not null" in transactions be confirmed?

This rather innocent suggestion brought an idea to us that constraints
could be quite simplified when it comes to their syntax, consider this:

val int check not_null(val)
val text check json(val)
val text check lenght(val) < 1000

to be used like this:

val int check not null
val text check json
val text check length() < 1000

more involved checks like this:

val text check not_null(val) and json(val) and length(val) < 1000

might be just simplified to:

val text check not null and json and length() < 1000

It almost reads like plain English. Isn't this just easier for an eye?

The reason we kept the column names in constraint definitions is that,
frankly speaking, we just did not know any better at the time it was about
to be implemented. It is a little bit more tricky to be able to use it
without column names because in Parser.g / Antlr we just bound the grammar
around constraints to a column name directly there. When column names are
not going to be there anymore, we need to bind it later in the code behind
the parser in server code. It is doable, it was just about being a little
bit more involved there.

Also, one reason to keep the name of a column was that we might specify
different columns in a constraint from a column that is defined on to have
cross-column constraints but we abandoned this idea altogether for other
reasons which rendered the occurrence of a column name in a constraint
definition redundant.

To have some overview of what would be possible to do with this proposal:

val3 text CHECK SOMECONSTRAINT('a');
val3 text CHECK JSON;
val3 text CHECK SOMECONSTRAINT('a') > 1;
val3 text CHECK SOMECONSTRAINT('a', 'b', 'c') > 1;
val3 text CHECK JSON AND LENGTH() < 600;
afternoon time CHECK afternoon >= '12:00:00' AND afternoon =< '23:59:59';
val3 text CHECK NOT NULL AND JSON AND LENGTH() < 1024

In addition to the specification of constraints without columns, what would
be possible to do is to also specify arguments to constraints. It is
currently not possible and there is no constraint which would accept
arguments to its function but I think that to be as flexible as possible
and prepare for the future, we might implement it as well.

Constraints in their current form are already usable however I just think
that if we do not simplify, align and extend the syntax right now, before
it is baked in in a release, then we will never do it as it will be quite
tricky to extend this without breaking it and maintaining two grammars at
the same time would be very complex if not flat out impossible.

Are you open to the simplification of constraint definitions as suggested
and what is your feedback about that? I already have a working POC which
just needs to be polished and tests fixed to accommodate the new approach.

Regards

(1) https://the-asf.slack.com/archives/CK23JSY2K/p1742409054164389

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

[Yifan Cai]

Re: reserved keywords, “check” is currently not, and I don’t think it needs to 
be a reserved keyword with the proposal.


From: C. Scott Andreas 
Sent: Thursday, April 10, 2025 7:59:35 AM
To: dev@cassandra.apache.org 
Cc: dev@cassandra.apache.org 
Subject: Re: Constraint's "not null" alignment with transactions and their 
simplification

If the proposal does not introduce “check” as a reserved keyword that would 
require quoting in existing DDL/DML, this concern doesn’t apply and the email 
below can be ignored. This might be the case if “CHECK NOT NULL” is the full 
token introduced rather than “CHECK” separately from constraints that are 
checked.

If “check” is introduced as a standalone reserved keyword: my primary feedback 
is on the introduction of reserved words in the CQL grammar that may affect 
compatibility of existing schemas.

In the Cassandra 3.x series, several new CQL reserved words were added (more 
than necessary) and subsequently backed out, because it required users to begin 
quoting schemas and introduced incompatibility between 3.x and 4.x for queries 
and DDL that “just worked” before.

The word “check” is used in many domains (test/evaluation engineering, finance, 
business processes, etc) and is likely to be used in user schemas. If the 
proposal introduces this as a reserved word that would require it to be quoted 
if used in table or column names, this will create incompatibility for existing 
user queries on upgrade.

Otherwise, ignore me. :)

Thanks,

– Scott

–––
Mobile

On Apr 10, 2025, at 7:47 AM, Jon Haddad  wrote:


This looks like a really nice improvement to me.


On Thu, Apr 10, 2025 at 7:27 AM Štefan Miklošovič 
mailto:smikloso...@apache.org>> wrote:
Recently, David Capwell was commenting on constraints in one of Slack threads 
(1) in dev channel and he suggested that the current form of "not null" 
constraint we have right now in place, e.g like this

create table ks.tb (id int primary key, val int check not_null(val));

could be instead of that form used like this:

create table ks.tb (id int primary key, val int check not null);

That is - without the name of a column in the constraint's argument. The 
reasoning behind that was that it is not only easier to read but there is also 
this concept in transactions (cep-15) where there is also "not null" used in 
some fashion and it would be nice if this was aligned so a user does not 
encounter two usages of "not null"-s which are written down differently, 
syntax-wise.

Could the usage of "not null" in transactions be confirmed?

This rather innocent suggestion brought an idea to us that constraints could be 
quite simplified when it comes to their syntax, consider this:

val int check not_null(val)
val text check json(val)
val text check lenght(val) < 1000

to be used like this:

val int check not null
val text check json
val text check length() < 1000

more involved checks like this:

val text check not_null(val) and json(val) and length(val) < 1000

might be just simplified to:

val text check not null and json and length() < 1000

It almost reads like plain English. Isn't this just easier for an eye?

The reason we kept the column names in constraint definitions is that, frankly 
speaking, we just did not know any better at the time it was about to be 
implemented. It is a little bit more tricky to be able to use it without column 
names because in Parser.g / Antlr we just bound the grammar around constraints 
to a column name directly there. When column names are not going to be there 
anymore, we need to bind it later in the code behind the parser in server code. 
It is doable, it was just about being a little bit more involved there.

Also, one reason to keep the name of a column was that we might specify 
different columns in a constraint from a column that is defined on to have 
cross-column constraints but we abandoned this idea altogether for other 
reasons which rendered the occurrence of a column name in a constraint 
definition redundant.

To have some overview of what would be possible to do with this proposal:

val3 text CHECK SOMECONSTRAINT('a');
val3 text CHECK JSON;
val3 text CHECK SOMECONSTRAINT('a') > 1;
val3 text CHECK SOMECONSTRAINT('a', 'b', 'c') > 1;
val3 text CHECK JSON AND LENGTH() < 600;
afternoon time CHECK afternoon >= '12:00:00' AND afternoon =< '23:59:59';
val3 text CHECK NOT NULL AND JSON AND LENGTH() < 1024

In addition to the specification of constraints without columns, what would be 
possible to do is to also specify arguments to constraints. It is currently not 
possible and there is no constraint which would accept arguments to its 
function but I think that to be as flexible as possible and prepare for the 
future, we might implement it as well.

Constraints in their current form are already usable however I just think that 
if we do not simplify, align and extend the syntax right now, before it is 
baked in in a release, then we will never do it 

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

[C. Scott Andreas]

If the proposal does not introduce “check” as a reserved keyword that would require quoting in existing DDL/DML, this concern doesn’t apply and the email below can be ignored. This might be the case if “CHECK NOT NULL” is the full token introduced rather than “CHECK” separately from constraints that are checked.If “check” is introduced as a standalone reserved keyword: my primary feedback is on the introduction of reserved words in the CQL grammar that may affect compatibility of existing schemas.In the Cassandra 3.x series, several new CQL reserved words were added (more than necessary) and subsequently backed out, because it required users to begin quoting schemas and introduced incompatibility between 3.x and 4.x for queries and DDL that “just worked” before.The word “check” is used in many domains (test/evaluation engineering, finance, business processes, etc) and is likely to be used in user schemas. If the proposal introduces this as a reserved word that would require it to be quoted if used in table or column names, this will create incompatibility for existing user queries on upgrade.Otherwise, ignore me. :)Thanks,– Scott–––MobileOn Apr 10, 2025, at 7:47 AM, Jon Haddad  wrote:This looks like a really nice improvement to me. On Thu, Apr 10, 2025 at 7:27 AM Štefan Miklošovič  wrote:Recently, David Capwell was commenting on constraints in one of Slack threads (1) in dev channel and he suggested that the current form of "not null" constraint we have right now in place, e.g like thiscreate table ks.tb (id int primary key, val int check not_null(val));could be instead of that form used like this:create table ks.tb (id int primary key, val int check not null);That is - without the name of a column in the constraint's argument. The reasoning behind that was that it is not only easier to read but there is also this concept in transactions (cep-15) where there is also "not null" used in some fashion and it would be nice if this was aligned so a user does not encounter two usages of "not null"-s which are written down differently, syntax-wise.Could the usage of "not null" in transactions be confirmed?This rather innocent suggestion brought an idea to us that constraints could be quite simplified when it comes to their syntax, consider this:val int check not_null(val)val text check json(val)val text check lenght(val) < 1000to be used like this:val int check not nullval text check jsonval text check length() < 1000more involved checks like this:val text check not_null(val) and json(val) and length(val) < 1000might be just simplified to:val text check not null and json and length() < 1000It almost reads like plain English. Isn't this just easier for an eye?The reason we kept the column names in constraint definitions is that, frankly speaking, we just did not know any better at the time it was about to be implemented. It is a little bit more tricky to be able to use it without column names because in Parser.g / Antlr we just bound the grammar around constraints to a column name directly there. When column names are not going to be there anymore, we need to bind it later in the code behind the parser in server code. It is doable, it was just about being a little bit more involved there.Also, one reason to keep the name of a column was that we might specify different columns in a constraint from a column that is defined on to have cross-column constraints but we abandoned this idea altogether for other reasons which rendered the occurrence of a column name in a constraint definition redundant.To have some overview of what would be possible to do with this proposal:val3 text CHECK SOMECONSTRAINT('a');val3 text CHECK JSON;val3 text CHECK SOMECONSTRAINT('a') > 1;val3 text CHECK SOMECONSTRAINT('a', 'b', 'c') > 1;val3 text CHECK JSON AND LENGTH() < 600;afternoon time CHECK afternoon >= '12:00:00' AND afternoon =< '23:59:59';val3 text CHECK NOT NULL AND JSON AND LENGTH() < 1024In addition to the specification of constraints without columns, what would be possible to do is to also specify arguments to constraints. It is currently not possible and there is no constraint which would accept arguments to its function but I think that to be as flexible as possible and prepare for the future, we might implement it as well. Constraints in their current form are already usable however I just think that if we do not simplify, align and extend the syntax right now, before it is baked in in a release, then we will never do it as it will be quite tricky to extend this without breaking it and maintaining two grammars at the same time would be very complex if not flat out impossible.Are you open to the simplification of constraint definitions as suggested and what is your feedback about that? I already have a working POC which just needs to be polished and tests fixed to accommodate the new approach.Regards(1) https://the-asf.slack.com/archives/CK23JSY2K/p1742409054164389

Re: [VOTE] Release Apache Cassandra 5.0.4

[Brandon Williams]

With 4 +1 votes (all binding!) and no -1, this vote has passed.  I'll
get the artifacts published.

On Mon, Apr 7, 2025 at 7:35 AM Brandon Williams
 wrote:
>
> Proposing the test build of Cassandra 5.0.4 for release.
>
> sha1: b81163b04b1d99036730ff233595d7bfb88611d1
> Git: https://github.com/apache/cassandra/tree/5.0.4-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1391/org/apache/cassandra/cassandra-all/5.0.4/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/5.0.4/
>
> The vote will be open for 72 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding
> +1s and no -1's.
>
> [1]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/5.0.4-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/5.0.4-tentative/NEWS.txt

Re: [DISCUSS] slack notifications for subprojects

[Joel Shepherd]

On 4/8/2025 11:31 PM, Mick Semb Wever wrote:

On Tue, 8 Apr 2025 at 23:59, Joel Shepherd  wrote:

I'm curious what the argument for pumping ticket notifications
into #cassandra-dev, etc., is, versus pumping them into a
dedicated channel.

Hi Joel,

for myself, and I'm guessing it's a popular concern, it is being able 
to especially see the new tickets created.  Many are often quick to 
triage or even resolve, and many desirable to ensure watching.  
Spotting them in the full feed, and/or keeping up consistently with 
the full feed is overwhelming if not just infeasible.  As an open 
established project it takes a bit of extra effort to stay on top of 
what's inbound.


Makes sense. This is one of those scenarios where I wish Slack gave the 
message recipient more control over incoming message routing but it is 
what it is.


Thanks for the explanation -- Joel.

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

[Jon Haddad]

This looks like a really nice improvement to me.


On Thu, Apr 10, 2025 at 7:27 AM Štefan Miklošovič 
wrote:

> Recently, David Capwell was commenting on constraints in one of Slack
> threads (1) in dev channel and he suggested that the current form of "not
> null" constraint we have right now in place, e.g like this
>
> create table ks.tb (id int primary key, val int check not_null(val));
>
> could be instead of that form used like this:
>
> create table ks.tb (id int primary key, val int check not null);
>
> That is - without the name of a column in the constraint's argument. The
> reasoning behind that was that it is not only easier to read but there is
> also this concept in transactions (cep-15) where there is also "not null"
> used in some fashion and it would be nice if this was aligned so a user
> does not encounter two usages of "not null"-s which are written down
> differently, syntax-wise.
>
> Could the usage of "not null" in transactions be confirmed?
>
> This rather innocent suggestion brought an idea to us that constraints
> could be quite simplified when it comes to their syntax, consider this:
>
> val int check not_null(val)
> val text check json(val)
> val text check lenght(val) < 1000
>
> to be used like this:
>
> val int check not null
> val text check json
> val text check length() < 1000
>
> more involved checks like this:
>
> val text check not_null(val) and json(val) and length(val) < 1000
>
> might be just simplified to:
>
> val text check not null and json and length() < 1000
>
> It almost reads like plain English. Isn't this just easier for an eye?
>
> The reason we kept the column names in constraint definitions is that,
> frankly speaking, we just did not know any better at the time it was about
> to be implemented. It is a little bit more tricky to be able to use it
> without column names because in Parser.g / Antlr we just bound the grammar
> around constraints to a column name directly there. When column names are
> not going to be there anymore, we need to bind it later in the code behind
> the parser in server code. It is doable, it was just about being a little
> bit more involved there.
>
> Also, one reason to keep the name of a column was that we might specify
> different columns in a constraint from a column that is defined on to have
> cross-column constraints but we abandoned this idea altogether for other
> reasons which rendered the occurrence of a column name in a constraint
> definition redundant.
>
> To have some overview of what would be possible to do with this proposal:
>
> val3 text CHECK SOMECONSTRAINT('a');
> val3 text CHECK JSON;
> val3 text CHECK SOMECONSTRAINT('a') > 1;
> val3 text CHECK SOMECONSTRAINT('a', 'b', 'c') > 1;
> val3 text CHECK JSON AND LENGTH() < 600;
> afternoon time CHECK afternoon >= '12:00:00' AND afternoon =< '23:59:59';
> val3 text CHECK NOT NULL AND JSON AND LENGTH() < 1024
>
> In addition to the specification of constraints without columns, what
> would be possible to do is to also specify arguments to constraints. It is
> currently not possible and there is no constraint which would accept
> arguments to its function but I think that to be as flexible as possible
> and prepare for the future, we might implement it as well.
>
> Constraints in their current form are already usable however I just think
> that if we do not simplify, align and extend the syntax right now, before
> it is baked in in a release, then we will never do it as it will be quite
> tricky to extend this without breaking it and maintaining two grammars at
> the same time would be very complex if not flat out impossible.
>
> Are you open to the simplification of constraint definitions as suggested
> and what is your feedback about that? I already have a working POC which
> just needs to be polished and tests fixed to accommodate the new approach.
>
> Regards
>
> (1) https://the-asf.slack.com/archives/CK23JSY2K/p1742409054164389
>

[RELEASE] Apache Cassandra 5.0.4 released

[Brandon Williams]

The Cassandra team is pleased to announce the release of Apache
Cassandra version 5.0.4.

Apache Cassandra is a fully distributed database. It is the right
choice when you need scalability and high availability without
compromising performance.

http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download section:

http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 5.0 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

[WARNING] Debian and RedHat package repositories have moved! Debian
/etc/apt/sources.list.d/cassandra.sources.list and RedHat
/etc/yum.repos.d/cassandra.repo files must be updated to the new
repository URLs. For Debian it is now https:/
/debian.cassandra.apache.org . For RedHat it is now
https://redhat.cassandra.apache.org/50x/ .

Enjoy!

[1]: CHANGES.txt
https://github.com/apache/cassandra/blob/cassandra-5.0.4/CHANGES.txt
[2]: NEWS.txt https://github.com/apache/cassandra/blob/cassandra-5.0.4/NEWS.txt
[3]: https://issues.apache.org/jira/browse/CASSANDRA

Re: [DISCUSS] 5.1 should be 6.0

[Jordan West]

I am +1 on 6.0 as well. The other topics brought up on this thread are
important, and we should address them, but I think we can move forward with
the version decision in parallel.

Jordan

On Thu, Apr 10, 2025 at 11:50 AM Brad  wrote:

> > . I assume JDK 21 may lead to removal of JDK 11 which is breaking change
>
> If we name it 6.0, I would hope we bump both Java and Python supported
> versions to align with their EOL status.
>
>- Java 11 with OpenJDK EOL was October 2024
>- Python 3.8 EOL was October 7, 2024
>
>
> On Thu, Apr 10, 2025 at 2:44 PM Ekaterina Dimitrova 
> wrote:
>
>> +1 on calling it 6.0. I assume JDK 21 may lead to removal of JDK 11 which
>> is breaking change (people need to upgrade to the common JDK version - 17
>> before upgrading to the next release)
>>
>> On Thu, 10 Apr 2025 at 14:40, Štefan Miklošovič 
>> wrote:
>>
>>> +1, I am also getting questions about the versioning recently and people
>>> themselves do not know what to call the next version like.
>>>
>>> On Thu, Apr 10, 2025 at 8:28 PM Jon Haddad 
>>> wrote:
>>>
 Bringing this back up.

 I don't think we have any reason to hold up renaming the version.  We
 can have a separate discussion about what upgrade paths are supported, but
 let's at least address this one issue of version number so we can have
 consistent messaging.  When i talk to people about the next release, I'd
 like to be consistent with what I call it, and have a unified voice as a
 project.

 Jon

 On Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever  wrote:

> .
>
>
>> If you mean only 4.1 and 5.0 would be online upgrade targets, I would
>> suggest we change that to T-3 so you encompass all “currently supported”
>> releases at the time the new branch is GAed.
>>
>> I think that's better actually, yeah. I was originally thinking T-2
>> from the "what calendar time frame is reasonable" perspective, but saying
>> "if you're on a currently supported branch you can upgrade to a release
>> that comes out" makes clean intuitive sense. That'd mean:
>>
>> 6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop support for 4.0.
>> API compatible guaranteed w/5.0.
>> 7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop support for 4.1.
>> API compatible guaranteed w/6.0.
>> 8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop support for 5.0.
>> API compatible guaranteed w/7.0.
>>
>
>
>
> I like this.
>
>

Re: [DISCUSS] 5.1 should be 6.0

[Mick Semb Wever]

Rather than only tackle this one-off, can we please put energy into Josh's
proposal raised above.

This discussion has both technical implications (tcm, accord, jdk21,
jvm-dtest-upgrades, …), legitimate external-facing communication concerns,
and people's general opinions.   I thought Josh's proposal captured all
these well and is a win-win for everyone.  It would be nice not to have to
repeat this conversation :D




On Thu, 10 Apr 2025 at 20:39, Štefan Miklošovič 
wrote:

> +1, I am also getting questions about the versioning recently and people
> themselves do not know what to call the next version like.
>
> On Thu, Apr 10, 2025 at 8:28 PM Jon Haddad 
> wrote:
>
>> Bringing this back up.
>>
>> I don't think we have any reason to hold up renaming the version.  We can
>> have a separate discussion about what upgrade paths are supported, but
>> let's at least address this one issue of version number so we can have
>> consistent messaging.  When i talk to people about the next release, I'd
>> like to be consistent with what I call it, and have a unified voice as a
>> project.
>>
>> Jon
>>
>> On Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever  wrote:
>>
>>> .
>>>
>>>
 If you mean only 4.1 and 5.0 would be online upgrade targets, I would
 suggest we change that to T-3 so you encompass all “currently supported”
 releases at the time the new branch is GAed.

 I think that's better actually, yeah. I was originally thinking T-2
 from the "what calendar time frame is reasonable" perspective, but saying
 "if you're on a currently supported branch you can upgrade to a release
 that comes out" makes clean intuitive sense. That'd mean:

 6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop support for 4.0. API
 compatible guaranteed w/5.0.
 7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop support for 4.1. API
 compatible guaranteed w/6.0.
 8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop support for 5.0. API
 compatible guaranteed w/7.0.

>>>
>>>
>>>
>>> I like this.
>>>
>>>

Re: [VOTE] Release Apache Cassandra 5.0.4

[Jon Haddad]

+1

On Mon, Apr 7, 2025 at 10:40 AM Caleb Rackliffe 
wrote:

> +1
>
> On Mon, Apr 7, 2025 at 7:37 AM Brandon Williams <
> brandonwilli...@apache.org> wrote:
>
>> Proposing the test build of Cassandra 5.0.4 for release.
>>
>> sha1: b81163b04b1d99036730ff233595d7bfb88611d1
>> Git: https://github.com/apache/cassandra/tree/5.0.4-tentative
>> Maven Artifacts:
>>
>> https://repository.apache.org/content/repositories/orgapachecassandra-1391/org/apache/cassandra/cassandra-all/5.0.4/
>>
>> The Source and Build Artifacts, and the Debian and RPM packages and
>> repositories, are available here:
>> https://dist.apache.org/repos/dist/dev/cassandra/5.0.4/
>>
>> The vote will be open for 72 hours (longer if needed). Everyone who
>> has tested the build is invited to vote. Votes by PMC members are
>> considered binding. A vote passes if there are at least three binding
>> +1s and no -1's.
>>
>> [1]: CHANGES.txt:
>> https://github.com/apache/cassandra/blob/5.0.4-tentative/CHANGES.txt
>> [2]: NEWS.txt:
>> https://github.com/apache/cassandra/blob/5.0.4-tentative/NEWS.txt
>>
>

Re: [DISCUSS] 5.1 should be 6.0

[Jordan West]

I don’t think there is any world where we can justify such major changes
being called 5.1. 5.0 had significantly less major changes. Mick, the
topics you bring up are important. But I don’t think they are required for
the community to decide we are calling this 6.0. We’ve tried that approach
and we’ve gone in circles. We should start new threads to prioritize those
discussions while closing the naming out. It’s taken way too long and it
confuses the community imo.

Jordan

On Thu, Apr 10, 2025 at 12:02 Mick Semb Wever  wrote:

> Rather than only tackle this one-off, can we please put energy into Josh's
> proposal raised above.
>
> This discussion has both technical implications (tcm, accord, jdk21,
> jvm-dtest-upgrades, …), legitimate external-facing communication concerns,
> and people's general opinions.   I thought Josh's proposal captured all
> these well and is a win-win for everyone.  It would be nice not to have to
> repeat this conversation :D
>
>
>
>
> On Thu, 10 Apr 2025 at 20:39, Štefan Miklošovič 
> wrote:
>
>> +1, I am also getting questions about the versioning recently and people
>> themselves do not know what to call the next version like.
>>
>> On Thu, Apr 10, 2025 at 8:28 PM Jon Haddad 
>> wrote:
>>
>>> Bringing this back up.
>>>
>>> I don't think we have any reason to hold up renaming the version.  We
>>> can have a separate discussion about what upgrade paths are supported, but
>>> let's at least address this one issue of version number so we can have
>>> consistent messaging.  When i talk to people about the next release, I'd
>>> like to be consistent with what I call it, and have a unified voice as a
>>> project.
>>>
>>> Jon
>>>
>>> On Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever  wrote:
>>>
 .


> If you mean only 4.1 and 5.0 would be online upgrade targets, I would
> suggest we change that to T-3 so you encompass all “currently supported”
> releases at the time the new branch is GAed.
>
> I think that's better actually, yeah. I was originally thinking T-2
> from the "what calendar time frame is reasonable" perspective, but saying
> "if you're on a currently supported branch you can upgrade to a release
> that comes out" makes clean intuitive sense. That'd mean:
>
> 6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop support for 4.0.
> API compatible guaranteed w/5.0.
> 7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop support for 4.1.
> API compatible guaranteed w/6.0.
> 8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop support for 5.0.
> API compatible guaranteed w/7.0.
>



 I like this.

Re: [DISCUSS] 5.1 should be 6.0

[Jon Haddad]

Bringing this back up.

I don't think we have any reason to hold up renaming the version.  We can
have a separate discussion about what upgrade paths are supported, but
let's at least address this one issue of version number so we can have
consistent messaging.  When i talk to people about the next release, I'd
like to be consistent with what I call it, and have a unified voice as a
project.

Jon

On Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever  wrote:

> .
>
>
>> If you mean only 4.1 and 5.0 would be online upgrade targets, I would
>> suggest we change that to T-3 so you encompass all “currently supported”
>> releases at the time the new branch is GAed.
>>
>> I think that's better actually, yeah. I was originally thinking T-2 from
>> the "what calendar time frame is reasonable" perspective, but saying "if
>> you're on a currently supported branch you can upgrade to a release that
>> comes out" makes clean intuitive sense. That'd mean:
>>
>> 6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop support for 4.0. API
>> compatible guaranteed w/5.0.
>> 7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop support for 4.1. API
>> compatible guaranteed w/6.0.
>> 8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop support for 5.0. API
>> compatible guaranteed w/7.0.
>>
>
>
>
> I like this.
>
>

Re: [DISCUSS] 5.1 should be 6.0

[Josh McKenzie]

+1 to 6.0.

On Thu, Apr 10, 2025, at 2:28 PM, Jon Haddad wrote:
> Bringing this back up.
> 
> I don't think we have any reason to hold up renaming the version.  We can 
> have a separate discussion about what upgrade paths are supported, but let's 
> at least address this one issue of version number so we can have consistent 
> messaging.  When i talk to people about the next release, I'd like to be 
> consistent with what I call it, and have a unified voice as a project.
> 
> Jon
> 
> On Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever  wrote:
>> .
>>
 If you mean only 4.1 and 5.0 would be online upgrade targets, I would 
 suggest we change that to T-3 so you encompass all “currently supported” 
 releases at the time the new branch is GAed.
>>> I think that's better actually, yeah. I was originally thinking T-2 from 
>>> the "what calendar time frame is reasonable" perspective, but saying "if 
>>> you're on a currently supported branch you can upgrade to a release that 
>>> comes out" makes clean intuitive sense. That'd mean:
>>> 
>>> 6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop support for 4.0. API 
>>> compatible guaranteed w/5.0.
>>> 7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop support for 4.1. API 
>>> compatible guaranteed w/6.0.
>>> 8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop support for 5.0. API 
>>> compatible guaranteed w/7.0.
>>> 
>> 
>> 
>> 
>> I like this.

Re: [DISCUSS] 5.1 should be 6.0

[Štefan Miklošovič]

+1, I am also getting questions about the versioning recently and people
themselves do not know what to call the next version like.

On Thu, Apr 10, 2025 at 8:28 PM Jon Haddad  wrote:

> Bringing this back up.
>
> I don't think we have any reason to hold up renaming the version.  We can
> have a separate discussion about what upgrade paths are supported, but
> let's at least address this one issue of version number so we can have
> consistent messaging.  When i talk to people about the next release, I'd
> like to be consistent with what I call it, and have a unified voice as a
> project.
>
> Jon
>
> On Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever  wrote:
>
>> .
>>
>>
>>> If you mean only 4.1 and 5.0 would be online upgrade targets, I would
>>> suggest we change that to T-3 so you encompass all “currently supported”
>>> releases at the time the new branch is GAed.
>>>
>>> I think that's better actually, yeah. I was originally thinking T-2 from
>>> the "what calendar time frame is reasonable" perspective, but saying "if
>>> you're on a currently supported branch you can upgrade to a release that
>>> comes out" makes clean intuitive sense. That'd mean:
>>>
>>> 6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop support for 4.0. API
>>> compatible guaranteed w/5.0.
>>> 7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop support for 4.1. API
>>> compatible guaranteed w/6.0.
>>> 8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop support for 5.0. API
>>> compatible guaranteed w/7.0.
>>>
>>
>>
>>
>> I like this.
>>
>>

Re: [DISCUSS] 5.1 should be 6.0

[Ekaterina Dimitrova]

+1 on calling it 6.0. I assume JDK 21 may lead to removal of JDK 11 which
is breaking change (people need to upgrade to the common JDK version - 17
before upgrading to the next release)

On Thu, 10 Apr 2025 at 14:40, Štefan Miklošovič 
wrote:

> +1, I am also getting questions about the versioning recently and people
> themselves do not know what to call the next version like.
>
> On Thu, Apr 10, 2025 at 8:28 PM Jon Haddad 
> wrote:
>
>> Bringing this back up.
>>
>> I don't think we have any reason to hold up renaming the version.  We can
>> have a separate discussion about what upgrade paths are supported, but
>> let's at least address this one issue of version number so we can have
>> consistent messaging.  When i talk to people about the next release, I'd
>> like to be consistent with what I call it, and have a unified voice as a
>> project.
>>
>> Jon
>>
>> On Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever  wrote:
>>
>>> .
>>>
>>>
 If you mean only 4.1 and 5.0 would be online upgrade targets, I would
 suggest we change that to T-3 so you encompass all “currently supported”
 releases at the time the new branch is GAed.

 I think that's better actually, yeah. I was originally thinking T-2
 from the "what calendar time frame is reasonable" perspective, but saying
 "if you're on a currently supported branch you can upgrade to a release
 that comes out" makes clean intuitive sense. That'd mean:

 6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop support for 4.0. API
 compatible guaranteed w/5.0.
 7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop support for 4.1. API
 compatible guaranteed w/6.0.
 8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop support for 5.0. API
 compatible guaranteed w/7.0.

>>>
>>>
>>>
>>> I like this.
>>>
>>>

Re: [DISCUSS] 5.1 should be 6.0

[Brad]

> . I assume JDK 21 may lead to removal of JDK 11 which is breaking change

If we name it 6.0, I would hope we bump both Java and Python supported
versions to align with their EOL status.

   - Java 11 with OpenJDK EOL was October 2024
   - Python 3.8 EOL was October 7, 2024


On Thu, Apr 10, 2025 at 2:44 PM Ekaterina Dimitrova 
wrote:

> +1 on calling it 6.0. I assume JDK 21 may lead to removal of JDK 11 which
> is breaking change (people need to upgrade to the common JDK version - 17
> before upgrading to the next release)
>
> On Thu, 10 Apr 2025 at 14:40, Štefan Miklošovič 
> wrote:
>
>> +1, I am also getting questions about the versioning recently and people
>> themselves do not know what to call the next version like.
>>
>> On Thu, Apr 10, 2025 at 8:28 PM Jon Haddad 
>> wrote:
>>
>>> Bringing this back up.
>>>
>>> I don't think we have any reason to hold up renaming the version.  We
>>> can have a separate discussion about what upgrade paths are supported, but
>>> let's at least address this one issue of version number so we can have
>>> consistent messaging.  When i talk to people about the next release, I'd
>>> like to be consistent with what I call it, and have a unified voice as a
>>> project.
>>>
>>> Jon
>>>
>>> On Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever  wrote:
>>>
 .


> If you mean only 4.1 and 5.0 would be online upgrade targets, I would
> suggest we change that to T-3 so you encompass all “currently supported”
> releases at the time the new branch is GAed.
>
> I think that's better actually, yeah. I was originally thinking T-2
> from the "what calendar time frame is reasonable" perspective, but saying
> "if you're on a currently supported branch you can upgrade to a release
> that comes out" makes clean intuitive sense. That'd mean:
>
> 6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop support for 4.0.
> API compatible guaranteed w/5.0.
> 7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop support for 4.1.
> API compatible guaranteed w/6.0.
> 8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop support for 5.0.
> API compatible guaranteed w/7.0.
>



 I like this.

Re: [DISCUSS] 5.1 should be 6.0

[C. Scott Andreas]

+1 6.0- Scott—MobileOn Apr 10, 2025, at 1:34 PM, Jeremy Hanna  wrote:+1 for 6.0 for TCM/Accord changes, making it easier to make a case to upgrade dependencies like the Java/Python versions.On Apr 10, 2025, at 3:24 PM, Bernardo Botella  wrote:+1 on 6.0On Apr 10, 2025, at 1:07 PM, Josh McKenzie  wrote:Let's keep this thread to just +1's on 6.0; I'll see about a proper isolated [DISCUSS] thread for my proposal above hopefully tomorrow, schedule permitting.On Thu, Apr 10, 2025, at 3:46 PM, Jeremiah Jordan wrote:+1 to 6.0On Thu, Apr 10, 2025 at 1:38 PM Josh McKenzie  wrote:+1 to 6.0.On Thu, Apr 10, 2025, at 2:28 PM, Jon Haddad wrote:Bringing this back up.I don't think we have any reason to hold up renaming the version.  We can have a separate discussion about what upgrade paths are supported, but let's at least address this one issue of version number so we can have consistent messaging.  When i talk to people about the next release, I'd like to be consistent with what I call it, and have a unified voice as a project.JonOn Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever  wrote:    .   If you mean only 4.1 and 5.0 would be online upgrade targets, I would suggest we change that to T-3 so you encompass all “currently supported” releases at the time the new branch is GAed.I think that's better actually, yeah. I was originally thinking T-2 from the "what calendar time frame is reasonable" perspective, but saying "if you're on a currently supported branch you can upgrade to a release that comes out" makes clean intuitive sense. That'd mean:6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop support for 4.0. API compatible guaranteed w/5.0.7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop support for 4.1. API compatible guaranteed w/6.0.8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop support for 5.0. API compatible guaranteed w/7.0.I like this.

Re: [DISCUSS] 5.1 should be 6.0

[Mick Semb Wever]

IIRC one of the reasons that was raised to bump to 5.0 was because of
Accord.  We realised latter when we pushed TCM and Accord out that the
version bump may have been premature (though the other opinion around
versioning remains around what upgrade paths we say we support being based
on what upgrade paths we run through CI, and those being bound by
jvm-dtest-upgrade's nature of where we support an overlapping jdk).

I'm not blocking on calling this release 6.0.  I don't care about the
number that accompanies the new features that land, I do care about our
testing of upgrade paths (cluster availability during upgrades, on our
recommended upgrade paths, should be paramount imho).  Adding jdk21 and
removing jdk11 is justification for 6.0, but this is just my opinion / what
i care about.  I've also heard valid reasons for TCM warranting the 6.0
version.   And I appreciate the need for the outside world to have more
consistency/preparation on what our next version is,  otherwise I wouldn't
see the rush to decide that version until we're feature-freezed and closer
to release branching time.

Back to Josh's proposal, let's please just remove the need for the
discussion and these long conversations altogether :-)




On Thu, 10 Apr 2025 at 21:15, Jordan West  wrote:

> I don’t think there is any world where we can justify such major changes
> being called 5.1. 5.0 had significantly less major changes. Mick, the
> topics you bring up are important. But I don’t think they are required for
> the community to decide we are calling this 6.0. We’ve tried that approach
> and we’ve gone in circles. We should start new threads to prioritize those
> discussions while closing the naming out. It’s taken way too long and it
> confuses the community imo.
>
> Jordan
>
> On Thu, Apr 10, 2025 at 12:02 Mick Semb Wever  wrote:
>
>> Rather than only tackle this one-off, can we please put energy into
>> Josh's proposal raised above.
>>
>> This discussion has both technical implications (tcm, accord, jdk21,
>> jvm-dtest-upgrades, …), legitimate external-facing communication concerns,
>> and people's general opinions.   I thought Josh's proposal captured all
>> these well and is a win-win for everyone.  It would be nice not to have to
>> repeat this conversation :D
>>
>>
>>
>>
>> On Thu, 10 Apr 2025 at 20:39, Štefan Miklošovič 
>> wrote:
>>
>>> +1, I am also getting questions about the versioning recently and people
>>> themselves do not know what to call the next version like.
>>>
>>> On Thu, Apr 10, 2025 at 8:28 PM Jon Haddad 
>>> wrote:
>>>
 Bringing this back up.

 I don't think we have any reason to hold up renaming the version.  We
 can have a separate discussion about what upgrade paths are supported, but
 let's at least address this one issue of version number so we can have
 consistent messaging.  When i talk to people about the next release, I'd
 like to be consistent with what I call it, and have a unified voice as a
 project.

 Jon

 On Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever  wrote:

> .
>
>
>> If you mean only 4.1 and 5.0 would be online upgrade targets, I would
>> suggest we change that to T-3 so you encompass all “currently supported”
>> releases at the time the new branch is GAed.
>>
>> I think that's better actually, yeah. I was originally thinking T-2
>> from the "what calendar time frame is reasonable" perspective, but saying
>> "if you're on a currently supported branch you can upgrade to a release
>> that comes out" makes clean intuitive sense. That'd mean:
>>
>> 6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop support for 4.0.
>> API compatible guaranteed w/5.0.
>> 7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop support for 4.1.
>> API compatible guaranteed w/6.0.
>> 8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop support for 5.0.
>> API compatible guaranteed w/7.0.
>>
>
>
>
> I like this.
>
>

Re: [DISCUSS] 5.1 should be 6.0

[David Capwell]

+1 to 6.0
Strong +1 to T-3, we should support 4.0/4.1 to 6.0 upgrades.

> On Apr 10, 2025, at 2:18 PM, C. Scott Andreas  wrote:
> 
> +1 6.0
> 
> - Scott
> 
> —
> Mobile
> 
>> On Apr 10, 2025, at 1:34 PM, Jeremy Hanna  wrote:
>> 
>> +1 for 6.0 for TCM/Accord changes, making it easier to make a case to 
>> upgrade dependencies like the Java/Python versions.
>> 
>>> On Apr 10, 2025, at 3:24 PM, Bernardo Botella 
>>>  wrote:
>>> 
>>> +1 on 6.0
>>> 
 On Apr 10, 2025, at 1:07 PM, Josh McKenzie  wrote:
 
 Let's keep this thread to just +1's on 6.0; I'll see about a proper 
 isolated [DISCUSS] thread for my proposal above hopefully tomorrow, 
 schedule permitting.
 
 On Thu, Apr 10, 2025, at 3:46 PM, Jeremiah Jordan wrote:
> +1 to 6.0
> 
> On Thu, Apr 10, 2025 at 1:38 PM Josh McKenzie  > wrote:
> 
> +1 to 6.0.
> 
> On Thu, Apr 10, 2025, at 2:28 PM, Jon Haddad wrote:
>> Bringing this back up.
>> 
>> I don't think we have any reason to hold up renaming the version.  We 
>> can have a separate discussion about what upgrade paths are supported, 
>> but let's at least address this one issue of version number so we can 
>> have consistent messaging.  When i talk to people about the next 
>> release, I'd like to be consistent with what I call it, and have a 
>> unified voice as a project.
>> 
>> Jon
>> 
>> On Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever > > wrote:
>> .
>>
>>> If you mean only 4.1 and 5.0 would be online upgrade targets, I would 
>>> suggest we change that to T-3 so you encompass all “currently 
>>> supported” releases at the time the new branch is GAed.
>> I think that's better actually, yeah. I was originally thinking T-2 from 
>> the "what calendar time frame is reasonable" perspective, but saying "if 
>> you're on a currently supported branch you can upgrade to a release that 
>> comes out" makes clean intuitive sense. That'd mean:
>> 
>> 6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop support for 4.0. API 
>> compatible guaranteed w/5.0.
>> 7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop support for 4.1. API 
>> compatible guaranteed w/6.0.
>> 8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop support for 5.0. API 
>> compatible guaranteed w/7.0.
>> 
>> 
>> 
>> 
>> I like this.
>>> 
>> 

Re: [DISCUSS] How we version our releases

[David Capwell]

> So here's what I'm thinking: a new release strategy that doesn't use .MINOR 
> of semver. Goals:

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)?  My first instinct is to not like this, but its not been easy to keep 
up with the JDK releases… every time we add a new JVM we need to make breaking 
changes...

> On Apr 10, 2025, at 1:54 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: [DISCUSS] 5.1 should be 6.0

[Jeremy Hanna]

+1 for 6.0 for TCM/Accord changes, making it easier to make a case to upgrade 
dependencies like the Java/Python versions.

> On Apr 10, 2025, at 3:24 PM, Bernardo Botella  
> wrote:
> 
> +1 on 6.0
> 
>> On Apr 10, 2025, at 1:07 PM, Josh McKenzie  wrote:
>> 
>> Let's keep this thread to just +1's on 6.0; I'll see about a proper isolated 
>> [DISCUSS] thread for my proposal above hopefully tomorrow, schedule 
>> permitting.
>> 
>> On Thu, Apr 10, 2025, at 3:46 PM, Jeremiah Jordan wrote:
>>> +1 to 6.0
>>> 
>>> On Thu, Apr 10, 2025 at 1:38 PM Josh McKenzie >> > wrote:
>>> 
>>> +1 to 6.0.
>>> 
>>> On Thu, Apr 10, 2025, at 2:28 PM, Jon Haddad wrote:
 Bringing this back up.
 
 I don't think we have any reason to hold up renaming the version.  We can 
 have a separate discussion about what upgrade paths are supported, but 
 let's at least address this one issue of version number so we can have 
 consistent messaging.  When i talk to people about the next release, I'd 
 like to be consistent with what I call it, and have a unified voice as a 
 project.
 
 Jon
 
 On Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever >>> > wrote:
 .

> If you mean only 4.1 and 5.0 would be online upgrade targets, I would 
> suggest we change that to T-3 so you encompass all “currently supported” 
> releases at the time the new branch is GAed.
 I think that's better actually, yeah. I was originally thinking T-2 from 
 the "what calendar time frame is reasonable" perspective, but saying "if 
 you're on a currently supported branch you can upgrade to a release that 
 comes out" makes clean intuitive sense. That'd mean:
 
 6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop support for 4.0. API 
 compatible guaranteed w/5.0.
 7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop support for 4.1. API 
 compatible guaranteed w/6.0.
 8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop support for 5.0. API 
 compatible guaranteed w/7.0.
 
 
 
 
 I like this.
> 

[DISCUSS] How we version our releases

[Josh McKenzie]

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: [DISCUSS] slack notifications for subprojects

[Ekaterina Dimitrova]

I’d say we mimic the current CASSANDRA tickets handling plus adding to the
#cassandra-sidecar. That means:

1) Open and close notifications to #cassandra-dev and #cassandra-sidecar
2) all other notifications to #cassandra-noise
WDYT?

On Tue, 8 Apr 2025 at 15:48, Josh McKenzie  wrote:

> Currently we don't have Qbot notifying us on CASSSIDECAR ticket creation
> and state change. Seems we could:
>
>1. notify in #cassandra-dev and #cassandra-sidecar
>2. notify in the #cassandra-sidecar channel
>
> My preference is for 1 since there's a tight relationship between what
> we're doing with the subprojects and the main db and there's probably
> shared interest there.
>
> Any other opinions?
>

Re: [DISCUSS] 5.1 should be 6.0

[Bernardo Botella]

+1 on 6.0

> On Apr 10, 2025, at 1:07 PM, Josh McKenzie  wrote:
> 
> Let's keep this thread to just +1's on 6.0; I'll see about a proper isolated 
> [DISCUSS] thread for my proposal above hopefully tomorrow, schedule 
> permitting.
> 
> On Thu, Apr 10, 2025, at 3:46 PM, Jeremiah Jordan wrote:
>> +1 to 6.0
>> 
>> On Thu, Apr 10, 2025 at 1:38 PM Josh McKenzie > > wrote:
>> 
>> +1 to 6.0.
>> 
>> On Thu, Apr 10, 2025, at 2:28 PM, Jon Haddad wrote:
>>> Bringing this back up.
>>> 
>>> I don't think we have any reason to hold up renaming the version.  We can 
>>> have a separate discussion about what upgrade paths are supported, but 
>>> let's at least address this one issue of version number so we can have 
>>> consistent messaging.  When i talk to people about the next release, I'd 
>>> like to be consistent with what I call it, and have a unified voice as a 
>>> project.
>>> 
>>> Jon
>>> 
>>> On Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever >> > wrote:
>>> .
>>>
 If you mean only 4.1 and 5.0 would be online upgrade targets, I would 
 suggest we change that to T-3 so you encompass all “currently supported” 
 releases at the time the new branch is GAed.
>>> I think that's better actually, yeah. I was originally thinking T-2 from 
>>> the "what calendar time frame is reasonable" perspective, but saying "if 
>>> you're on a currently supported branch you can upgrade to a release that 
>>> comes out" makes clean intuitive sense. That'd mean:
>>> 
>>> 6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop support for 4.0. API 
>>> compatible guaranteed w/5.0.
>>> 7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop support for 4.1. API 
>>> compatible guaranteed w/6.0.
>>> 8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop support for 5.0. API 
>>> compatible guaranteed w/7.0.
>>> 
>>> 
>>> 
>>> 
>>> I like this.

Re: [DISCUSS] 5.1 should be 6.0

[Berenguer Blasi]

+1 6.0

On 10/4/25 23:57, David Capwell wrote:

+1 to 6.0
Strong +1 to T-3, we should support 4.0/4.1 to 6.0 upgrades.

On Apr 10, 2025, at 2:18 PM, C. Scott Andreas  
wrote:


+1 6.0

- Scott

—
Mobile

On Apr 10, 2025, at 1:34 PM, Jeremy Hanna 
 wrote:


 +1 for 6.0 for TCM/Accord changes, making it easier to make a case 
to upgrade dependencies like the Java/Python versions.


On Apr 10, 2025, at 3:24 PM, Bernardo Botella 
 wrote:


+1 on 6.0

On Apr 10, 2025, at 1:07 PM, Josh McKenzie  
wrote:


Let's keep this thread to just +1's on 6.0; I'll see about a 
proper isolated [DISCUSS] thread for my proposal above hopefully 
tomorrow, schedule permitting.


On Thu, Apr 10, 2025, at 3:46 PM, Jeremiah Jordan wrote:

+1 to 6.0

On Thu, Apr 10, 2025 at 1:38 PM Josh McKenzie 
 wrote:



+1 to 6.0.

On Thu, Apr 10, 2025, at 2:28 PM, Jon Haddad wrote:

Bringing this back up.

I don't think we have any reason to hold up renaming the
version.  We can have a separate discussion about what
upgrade paths are supported, but let's at least address this
one issue of version number so we can have consistent
messaging.  When i talk to people about the next release,
I'd like to be consistent with what I call it, and have a
unified voice as a project.

Jon

On Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever
 wrote:

    .


If you mean only 4.1 and 5.0 would be online
upgrade targets, I would suggest we change that to
T-3 so you encompass all “currently supported”
releases at the time the new branch is GAed.

I think that's better actually, yeah. I was
originally thinking T-2 from the "what calendar time
frame is reasonable" perspective, but saying "if
you're on a currently supported branch you can
upgrade to a release that comes out" makes clean
intuitive sense. That'd mean:

6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop
support for 4.0. API compatible guaranteed w/5.0.
7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop
support for 4.1. API compatible guaranteed w/6.0.
8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop
support for 5.0. API compatible guaranteed w/7.0.




I like this.

Re: [DISCUSS] 5.1 should be 6.0

[guo Maxwell]

+1 to 6.0

Berenguer Blasi  于2025年4月11日周五 13:53写道：

> +1 6.0
> On 10/4/25 23:57, David Capwell wrote:
>
> +1 to 6.0
> Strong +1 to T-3, we should support 4.0/4.1 to 6.0 upgrades.
>
> On Apr 10, 2025, at 2:18 PM, C. Scott Andreas 
>  wrote:
>
> +1 6.0
>
> - Scott
>
> —
> Mobile
>
> On Apr 10, 2025, at 1:34 PM, Jeremy Hanna 
>  wrote:
>
>  +1 for 6.0 for TCM/Accord changes, making it easier to make a case to
> upgrade dependencies like the Java/Python versions.
>
> On Apr 10, 2025, at 3:24 PM, Bernardo Botella
>   wrote:
>
> +1 on 6.0
>
> On Apr 10, 2025, at 1:07 PM, Josh McKenzie 
>  wrote:
>
> Let's keep this thread to just +1's on 6.0; I'll see about a proper
> isolated [DISCUSS] thread for my proposal above hopefully tomorrow,
> schedule permitting.
>
> On Thu, Apr 10, 2025, at 3:46 PM, Jeremiah Jordan wrote:
>
> +1 to 6.0
>
> On Thu, Apr 10, 2025 at 1:38 PM Josh McKenzie 
> wrote:
>
>
> +1 to 6.0.
>
> On Thu, Apr 10, 2025, at 2:28 PM, Jon Haddad wrote:
>
> Bringing this back up.
>
> I don't think we have any reason to hold up renaming the version.  We can
> have a separate discussion about what upgrade paths are supported, but
> let's at least address this one issue of version number so we can have
> consistent messaging.  When i talk to people about the next release, I'd
> like to be consistent with what I call it, and have a unified voice as a
> project.
>
> Jon
>
> On Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever  wrote:
>
> .
>
>
> If you mean only 4.1 and 5.0 would be online upgrade targets, I would
> suggest we change that to T-3 so you encompass all “currently supported”
> releases at the time the new branch is GAed.
>
> I think that's better actually, yeah. I was originally thinking T-2 from
> the "what calendar time frame is reasonable" perspective, but saying "if
> you're on a currently supported branch you can upgrade to a release that
> comes out" makes clean intuitive sense. That'd mean:
>
> 6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop support for 4.0. API
> compatible guaranteed w/5.0.
> 7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop support for 4.1. API
> compatible guaranteed w/6.0.
> 8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop support for 5.0. API
> compatible guaranteed w/7.0.
>
>
>
>
> I like this.
>
>
>
>
>

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

[David Capwell]

I am biased but I do prefer

val3 text CHECK NOT NULL AND JSON AND LENGTH() < 1024

Here is a similar accord CQL

BEGIN TRANSACTION
  LET a = (…);
  IF a IS NOT NULL 
  AND a.b IS NOT NULL 
  AND a.c IS NULL; THEN
— profit
  END IF
COMMIT TRANSACTION

> On Apr 10, 2025, at 8:46 AM, Yifan Cai  wrote:
> 
> Re: reserved keywords, “check” is currently not, and I don’t think it needs 
> to be a reserved keyword with the proposal.
> 
> From: C. Scott Andreas 
> Sent: Thursday, April 10, 2025 7:59:35 AM
> To: dev@cassandra.apache.org 
> Cc: dev@cassandra.apache.org 
> Subject: Re: Constraint's "not null" alignment with transactions and their 
> simplification
>  
> If the proposal does not introduce “check” as a reserved keyword that would 
> require quoting in existing DDL/DML, this concern doesn’t apply and the email 
> below can be ignored. This might be the case if “CHECK NOT NULL” is the full 
> token introduced rather than “CHECK” separately from constraints that are 
> checked.
> 
> If “check” is introduced as a standalone reserved keyword: my primary 
> feedback is on the introduction of reserved words in the CQL grammar that may 
> affect compatibility of existing schemas.
> 
> In the Cassandra 3.x series, several new CQL reserved words were added (more 
> than necessary) and subsequently backed out, because it required users to 
> begin quoting schemas and introduced incompatibility between 3.x and 4.x for 
> queries and DDL that “just worked” before.
> 
> The word “check” is used in many domains (test/evaluation engineering, 
> finance, business processes, etc) and is likely to be used in user schemas. 
> If the proposal introduces this as a reserved word that would require it to 
> be quoted if used in table or column names, this will create incompatibility 
> for existing user queries on upgrade.
> 
> Otherwise, ignore me. :)
> 
> Thanks,
> 
> – Scott
> 
> –––
> Mobile
> 
>> On Apr 10, 2025, at 7:47 AM, Jon Haddad  wrote:
>> 
>> 
>> This looks like a really nice improvement to me. 
>> 
>> 
>> On Thu, Apr 10, 2025 at 7:27 AM Štefan Miklošovič > > wrote:
>> Recently, David Capwell was commenting on constraints in one of Slack 
>> threads (1) in dev channel and he suggested that the current form of "not 
>> null" constraint we have right now in place, e.g like this
>> 
>> create table ks.tb (id int primary key, val int check not_null(val));
>> 
>> could be instead of that form used like this:
>> 
>> create table ks.tb (id int primary key, val int check not null);
>> 
>> That is - without the name of a column in the constraint's argument. The 
>> reasoning behind that was that it is not only easier to read but there is 
>> also this concept in transactions (cep-15) where there is also "not null" 
>> used in some fashion and it would be nice if this was aligned so a user does 
>> not encounter two usages of "not null"-s which are written down differently, 
>> syntax-wise.
>> 
>> Could the usage of "not null" in transactions be confirmed?
>> 
>> This rather innocent suggestion brought an idea to us that constraints could 
>> be quite simplified when it comes to their syntax, consider this:
>> 
>> val int check not_null(val)
>> val text check json(val)
>> val text check lenght(val) < 1000
>> 
>> to be used like this:
>> 
>> val int check not null
>> val text check json
>> val text check length() < 1000
>> 
>> more involved checks like this:
>> 
>> val text check not_null(val) and json(val) and length(val) < 1000
>> 
>> might be just simplified to:
>> 
>> val text check not null and json and length() < 1000
>> 
>> It almost reads like plain English. Isn't this just easier for an eye?
>> 
>> The reason we kept the column names in constraint definitions is that, 
>> frankly speaking, we just did not know any better at the time it was about 
>> to be implemented. It is a little bit more tricky to be able to use it 
>> without column names because in Parser.g / Antlr we just bound the grammar 
>> around constraints to a column name directly there. When column names are 
>> not going to be there anymore, we need to bind it later in the code behind 
>> the parser in server code. It is doable, it was just about being a little 
>> bit more involved there.
>> 
>> Also, one reason to keep the name of a column was that we might specify 
>> different columns in a constraint from a column that is defined on to have 
>> cross-column constraints but we abandoned this idea altogether for other 
>> reasons which rendered the occurrence of a column name in a constraint 
>> definition redundant.
>> 
>> To have some overview of what would be possible to do with this proposal:
>> 
>> val3 text CHECK SOMECONSTRAINT('a');
>> val3 text CHECK JSON;
>> val3 text CHECK SOMECONSTRAINT('a') > 1;
>> val3 text CHECK SOMECONSTRAINT('a', 'b', 'c') > 1;
>> val3 text CHECK JSON AND LENGTH() < 600;
>> afternoon time CHECK afternoon >= '12:00:00' AND afternoon =< '23:59:59';
>> val3 text CHECK NOT NUL

Re: [DISCUSS] 5.1 should be 6.0

[Jeremiah Jordan]

+1 to 6.0

On Thu, Apr 10, 2025 at 1:38 PM Josh McKenzie  wrote:

> +1 to 6.0.
>
> On Thu, Apr 10, 2025, at 2:28 PM, Jon Haddad wrote:
>
> Bringing this back up.
>
> I don't think we have any reason to hold up renaming the version.  We can
> have a separate discussion about what upgrade paths are supported, but
> let's at least address this one issue of version number so we can have
> consistent messaging.  When i talk to people about the next release, I'd
> like to be consistent with what I call it, and have a unified voice as a
> project.
>
> Jon
>
> On Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever  wrote:
>
> .
>
>
> If you mean only 4.1 and 5.0 would be online upgrade targets, I would
> suggest we change that to T-3 so you encompass all “currently supported”
> releases at the time the new branch is GAed.
>
> I think that's better actually, yeah. I was originally thinking T-2 from
> the "what calendar time frame is reasonable" perspective, but saying "if
> you're on a currently supported branch you can upgrade to a release that
> comes out" makes clean intuitive sense. That'd mean:
>
> 6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop support for 4.0. API
> compatible guaranteed w/5.0.
> 7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop support for 4.1. API
> compatible guaranteed w/6.0.
> 8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop support for 5.0. API
> compatible guaranteed w/7.0.
>
>
>
>
> I like this.
>
>

Re: [DISCUSS] 5.1 should be 6.0

[Josh McKenzie]

Let's keep this thread to just +1's on 6.0; I'll see about a proper isolated 
[DISCUSS] thread for my proposal above hopefully tomorrow, schedule permitting.

On Thu, Apr 10, 2025, at 3:46 PM, Jeremiah Jordan wrote:
> +1 to 6.0
> 
> On Thu, Apr 10, 2025 at 1:38 PM Josh McKenzie  wrote:
>> __
>> +1 to 6.0.
>> 
>> On Thu, Apr 10, 2025, at 2:28 PM, Jon Haddad wrote:
>>> Bringing this back up.
>>> 
>>> I don't think we have any reason to hold up renaming the version.  We can 
>>> have a separate discussion about what upgrade paths are supported, but 
>>> let's at least address this one issue of version number so we can have 
>>> consistent messaging.  When i talk to people about the next release, I'd 
>>> like to be consistent with what I call it, and have a unified voice as a 
>>> project.
>>> 
>>> Jon
>>> 
>>> On Thu, Jan 30, 2025 at 1:41 AM Mick Semb Wever  wrote:
 .

>> If you mean only 4.1 and 5.0 would be online upgrade targets, I would 
>> suggest we change that to T-3 so you encompass all “currently supported” 
>> releases at the time the new branch is GAed.
> I think that's better actually, yeah. I was originally thinking T-2 from 
> the "what calendar time frame is reasonable" perspective, but saying "if 
> you're on a currently supported branch you can upgrade to a release that 
> comes out" makes clean intuitive sense. That'd mean:
> 
> 6.0: 5.0, 4.1, 4.0 online upgrades supported. Drop support for 4.0. API 
> compatible guaranteed w/5.0.
> 7.0: 6.0, 5.0, 4.1 online upgrades supported. Drop support for 4.1. API 
> compatible guaranteed w/6.0.
> 8.0: 7.0, 6.0, 5.0 online upgrades supported. Drop support for 5.0. API 
> compatible guaranteed w/7.0.
> 
 
 
 
 I like this.

Project hygiene on old PRs

[Bernardo Botella]

Hi everyone!

First of all, this may have come out before, and I understand it is really hard 
to keep a tidy house with so many different collaborations. But, I can't help 
the feeling that coming to the main Apache Cassandra repository and seeing more 
than 600 open PRs, some of them without activity for 5+ years, gives the wrong 
impression about the love and care that we all share for this code base. I 
think we can find an easy to follow agreement to try and keep things a bit 
tidier. I wanted to propose some kind of "rule" that allow us to directly close 
PRs that haven't had activity in a reasonable and conservative amount of time 
of, let's say, 6 months? I want to reiterate that I mean no activity at all for 
six months from the PR author. I understand that complex PRs can be opened for 
longer than that period, and that's perfectly fine.

What do you all think?

Bernardo