, Stefan via dev
mailto:dev@cassandra.apache.org>> a écrit :
Hi Benjamin,
in other words, anything we have @Deprecated annotation on top of (or anything
you want to annotate with it). Does it help with the explanation?
For the initial phase, I plan to just put "since" everywhere (int
Hi Benjamin,
in other words, anything we have @Deprecated annotation on top of (or anything
you want to annotate with it). Does it help with the explanation?
For the initial phase, I plan to just put "since" everywhere (into every
already existing @Deprecated annotation) and we leave out
13 oct. 2023 à 14:11, Miklosovic, Stefan via dev
mailto:dev@cassandra.apache.org>> a écrit :
Maybe for better understanding what we talk about, there is the PR which
implements the changes suggested here (1)
It is clear that @Deprecated is not used exclusively on JMX / Configuration
Maybe for better understanding what we talk about, there is the PR which
implements the changes suggested here (1)
It is clear that @Deprecated is not used exclusively on JMX / Configuration but
we use it internally as well. This is a very delicate topic and we need to go,
basically, one by
your next release will not contain any stuff which
should not be there. E.g. when we release 6.0, all 4.0 stuff can go away etc ...
____
From: Miklosovic, Stefan via dev
Sent: Friday, October 13, 2023 15:00
To: dev@cassandra.apache.org
Cc: Miklosovic, Stefan
S
Hi list,
is anybody against cutting some 3.x and 4.x releases? I think that is nice to
do before summit. The last 4.x were released late July, 3.0 in the middle of
May. There is quite a lot of changes in these branches.
I can release it all.
What is your opinion?
Regards
for them as well :-)
[1] https://issues.apache.org/jira/browse/CASSANDRA-18773
On Fri, 3 Nov 2023 at 22:55, Miklosovic, Stefan via dev
wrote:
>
> Hi list,
>
> is anybody against cutting some 3.x and 4.x releases? I think that is nice to
> do before summit. The last 4.x were rel
Hi,
similarly as for Cassandra 1.x and 2.x deprecations removal done in
CASSANDRA-18959, you are welcome to comment on the removal of all stuff
deprecated in 3.x (1).
If nobody objects after couple days I would like to proceed to the actual
removal. Please tell me if you want something to
Sure we can do that just for trunk. No problem with that. Hence, I am parking
this effort for a while.
From: Mick Semb Wever
Sent: Monday, October 30, 2023 22:56
To: dev@cassandra.apache.org
Subject: Re: Removal of deprecations added in Cassandra 3.x
ortant feature for me to win some internal company bet
My 2 cents,
German
________
From: Miklosovic, Stefan via dev
mailto:dev@cassandra.apache.org>>
Sent: Thursday, October 26, 2023 4:23 AM
To: dev@cassandra.apache.org<mailto:dev@cassandra.
On Mon, Oct 30, 2023, at 11:28 AM, Miklosovic, Stefan via dev wrote:
I could not agree more with what Benjamin just wrote.
It is truly more about the visibility of the progress. If one looks at this
(1), well, that seems like a pretty much finished epic, isn't it? If we make ML
and Jira the only
Do I understand it correctly that this is basically the case of "deprecated on
introduction" as we know that it will not be necessary the very next version?
I think that not everybody is upgrading from version to version as they appear.
If somebody upgrades from 4.0 to 5.1 (which we seem to
What Maxim proposes in the last paragraph would be definitely helpful. Not for
the project only but for a broader audience, companies etc., too.
Until this thread was started, my assumption was that "there will be 5.0 on
summit with TCM and Accord and it somehow just happens". More transparent
Hi list,
this is the follow-up thread after we discussed the addition of Deprecated
annotations with "since" in the code. It was merged to 5.0 and trunk under
18912.
I have added all the mappings under (1). There are tables for each major
version of Cassandra with links to all places where we
I can't view it either.
From: guo Maxwell
Sent: Monday, November 6, 2023 11:40
To: dev@cassandra.apache.org
Subject: Re: Road to 5.0-GA (was: [VOTE] Release Apache Cassandra 5.0-alpha2)
NetApp Security WARNING: This is an external email. Do not click
The link is fixed. Thanks!
From: Miklosovic, Stefan
Sent: Monday, November 6, 2023 11:42
To: dev@cassandra.apache.org
Subject: Re: Road to 5.0-GA (was: [VOTE] Release Apache Cassandra 5.0-alpha2)
I can't view it either.
To double check the reasoning behind this proposal:
1) is 5.1 going to contain only TCM / Accord when it comes to new features? In
other words, 5.1, except these two, will only ever contain bugfixes from older
branches (merging them up) or fixes for TCM / Accord itself (which will be
st, invest to reap returns, etc.
On Fri, Oct 13, 2023, at 9:16 AM, Miklosovic, Stefan via dev wrote:
I forgot the round #3.
That would consist of an ant task which would scan the source. Since we
enforced that each Deprecation annotation has to have its "since" on compile
time, we ca
For completeness, there is this thread (1) where we already decided that sigar
is OK to be removed completely.
I think that OSHI is way better lib to have, I am +1 on this proposal.
Currently the deal seems to be that this will go just to trunk.
(1)
Great news! Congratulations.
From: Josh McKenzie
Sent: Monday, January 8, 2024 19:19
To: dev
Subject: Welcome Maxim Muzafarov as Cassandra Committer
EXTERNAL EMAIL - USE CAUTION when clicking links or attachments
The Apache Cassandra PMC is pleased to
I would like to know whose idea was it to align it like it is currently done in
the first place. Maybe we are missing something important like why it was done
like that? If there is no reason, we might just start to align it as other DB
offerings do. My initial proposal to support both is more
My personal bet is that from the very beginning, Cassandra was more
"number-centric" and right alignment just made more sense back then,
considering strings as an afterthought. Another explanation is that nobody
actually put any work to it to distinguish strings and numbers and it stayed
like
Hi Claude,
while technically possible, I do not see a lot of people would use this. I am
for straightforward -H option instead of introducing -Hn which seems to bring
almost no value and brings discrepancy into the nodetool flags. I think there
are other -H outputs for other commands, are not
Wow, great news! Congratulations on your committership, Mike.
From: Benjamin Lerer
Sent: Friday, December 8, 2023 15:41
To: dev@cassandra.apache.org
Subject: Welcome Mike Adamson as Cassandra committer
EXTERNAL EMAIL - USE CAUTION when clicking links or
//github.com/apache/cassandra/pull/2853/files#diff-4e5b9f6d0d76ab9ace1bd805efe5788bb5d23c84c25ccf75b9896f20b46a1879
Thanks and regards
________________
From: Miklosovic, Stefan via dev
Sent: Monday, October 30, 2023 23:07
To: dev@cassandra.apache.org
Cc: Miklosovic, Stefan
Subject: Re: Removal of deprecatio
I feel like this thread deserves an update.
This CEP was put in a dormant state because there was one quite substantial
flaw, that is that if a node is misconfigured in such a way that it would
accept weaker passwords than other nodes in a cluster, it would not be safe.
The security of such
You wrote in the CEP:
As we mentioned in the motivation section, we currently have some guardrails
for columns size in place which can be extended for other data types.
Those guardrails will take preference over the defined constraints in the
schema, and a SCHEMA ALTER adding constraints that
perate. With that vision, if a customer tries to “ignore” the actual
limits set by the operator by adding more relaxed constraints, it gets a nice
message saying that “that is not allowed for the cluster, please contact your
admin".
On Jun 3, 2024, at 2:51 PM, Miklosovic, Stefan via
28 matches
Mail list logo
