+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,
+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, maki
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 acti
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
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, Yifa
> 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,
+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
+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 wr
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
- exc
+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 o
+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
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
+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 s
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 upgra
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
+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/
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 b
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 propos
> . 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
+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
+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 se
+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 numbe
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
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
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 p
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 p
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/apach
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: Const
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 tha
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
30 matches
Mail list logo
