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
+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
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
“ 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
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
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
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
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
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
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.
"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
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/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
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
"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
> 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,
+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
>
> 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
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.
19 matches
Mail list logo
