Proposing the test build of Cassandra 4.0.11 for release.
sha1: f8584b943e7cd62ed4cb66ead2c9b4a8f1c7f8b5
Git: https://github.com/apache/cassandra/tree/4.0.11-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1303/org/apache/cassandra/cassandra-all/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
Checked
- signing correct
- checksums are correct
- source ar
+1
On Thu, Jul 13, 2023, 2:13 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:
> Proposing the test build of Cassandra 4.0.11 for release.
>
> sha1: f8584b943e7cd62ed4cb66ead2c9b4a8f1c7f8b5
> Git: https://github.com/apache/cassandra/tree/4.0.11-tentative
> Maven Artifacts:
> https://r
> I just find it ridiculous we can not change "someProperty: 10" to "Some
> Property: 10" and there is so much red tape about that.
Well, we're talking about programmatic parsing here. This feels like
complaining about a compiler that won't let you build if you're missing a ;
We *can* change it,
"From what I see you guys want to condition any change by offering json/yaml as well."I don't think I've seen a proposal to block changes to nodetool output on machine-parseable formats in
this thread.Additions of new delimited fields to nodetool output are mostly straightforward. Changes to fiel
For example Dinesh said this:
"Until nodetool can support JSON as output format for all interaction and there
is a significant adoption in the user community, I would strongly advise
against making breaking changes to the CLI output."
That is where I get the need to have a JSON output in order
Dinesh's message cautions against making "breaking" changes that are likely to break parsing of output by current users (e.g., changes to naming/meaning/position of existing fields vs. adding new ones). I don't read his message as saying that any change to nodetool output is conditional on
offeri
On Thu, Jul 13, 2023 at 9:44 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:
> For example Dinesh said this:
>
> "Until nodetool can support JSON as output format for all interaction and
> there is a significant adoption in the user community, I would strongly
> advise against making
"Dinesh's message cautions against making "breaking" changes that are likely to
break parsing of output by current users (e.g., changes to naming/meaning/"
That is 100% correct. So by that logic, changing the output which you grep on
to something else will break your scripts if you expect it the
I am starting to slowly but surely share same opinion. Maybe we should just
stop advancing this discussion altogether and we should rather focus on a way
how to implement alternative output to nodetool etc. We probably need to do
this command by command.
Let's take this discussion in a different direction: If we add a --legacy
argument where we are supporting an old version for those who
need/want it but have the (breaking) changes on the default this feels like a
compromise - and then we can deprecate the legacy format without impacting
inno
On German’s point, to be honest in pre-4.1 any new changes we tried to add
with a flag after concerns for breaking changes were raised. So in that
sense I think it will be confusing to flip that to - new output by default
and moving to legacy the old one
On Thu, 13 Jul 2023 at 12:09, German Eichbe
All,
I am working with clusters with different Cassandra versions and have been
using some cqlsh which "just worked". Recently I wanted to use virtual tables
and ran into [1]. After that I filed [2].
Brandon states that "do not use a cqlsh that is from a different version than
what is distribu
Forgot the references:
[1] https://the-asf.slack.com/archives/CJZLTM05A/p1686771286554899
[2] https://issues.apache.org/jira/browse/CASSANDRA-18666
From: German Eichberger via dev
Sent: Thursday, July 13, 2023 10:14 AM
To: dev@cassandra.apache.org
Subject: [EXTERN
You forgot to link references,
https://issues.apache.org/jira/browse/CASSANDRA-18666 has it all
though I think
I think it's too late to align versions, that cat is out of the bag.
What we can do though is what I last suggested there: keep the C*
version somewhere in cqlsh and warn when it doesn't
“ keep the C*
version somewhere in cqlsh and warn when it doesn't match the server.”
+1 on this suggestion. I had horrible experience recently with things
changing their versioning in another project. It brings mostly confusion.
Warning and adding C* version makes it simple and obvious. No need to
This adds maintenance overhead but is a potential alternative. I would only
flip the flag. I would prefer to make the default "legacy" output and innovate
behind a "--output-format=v2" flag. That way tools do not break or have to
change to pass in the new flag.
Ideally we should always version
+1
> On Jul 13, 2023, at 12:12 AM, Miklosovic, Stefan
> wrote:
>
> Proposing the test build of Cassandra 4.0.11 for release.
>
> sha1: f8584b943e7cd62ed4cb66ead2c9b4a8f1c7f8b5
> Git: https://github.com/apache/cassandra/tree/4.0.11-tentative
> Maven Artifacts:
> https://repository.apache.org/c
I agree that a CEP is a good idea, I'll discuss with Jeff and hope to draft
something.
On Wed, Jul 12, 2023 at 6:13 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:
> CEP is a great idea. The devil is in details and while this looks cool, it
> will definitely not hurt to have the nuan
19 matches
Mail list logo
