his is a bug in the
system. The project obviously aims to serve end users, but the developer
community is the actual project and it is fine to serve that demographic first,
or only.
I agree we want to improve our documentation, but this is not the right way to
go about it.
On 1 May 2025, at 13:19, Mik
.
Patrich that LLM suggestion might be a life saver, let me try that!
From: Miklosovic, Stefan via dev
Sent: 01 May 2025 08:07
To: David Capwell ; dev@cassandra.apache.org
Cc: Miklosovic, Stefan
Subject: Re: [DISCUSS] Requirement to document features before releasing
# Sparse
Multiple key transaction support, bringing Apache Cassandra cluster to the RDMS
world!
# Dense
…
Here are the current limitations, …
Here is where we alter Apache Cassandra’s behavior to be more inline with SQL,
...
On Apr 30, 2025, at 1:38 PM, Miklosovic, Stefan via dev
wrote
to leave them as experimental
forever, not desiring to take on the burden of documenting something that’s
already merged in and usable by experts.
Curious what others think.
On Wed, Apr 30, 2025, at 12:10 PM, Miklosovic, Stefan via dev wrote:
I am on OpenSearchCon and there was a discussion
cassandra-easy-stress maybe?
Seems to be minimal divergence from easy-cass-stress and will be aligned with
cassandra-analytics and cassandra-sidecar while not clashing with
cassandra-stress. (and what is going to be donated is indeed something _easier_
than the legacy stress tool, right?)
From
I am on OpenSearchCon and there was a discussion about the documentation of
features. In a nutshell, the policy they seem to have is that there are some
minimal requirements for documentation in place for each feature introduced.
That way, there is no way (or it is greatly minimised) that there
Seeing this thread where we discuss about deprecations, I use this for asking
if there is some action to take when looking into (1) I conducted a small
research for some time ago.
There are tables containing what was deprecated and when. We have removed all
deprecated code from 1.x and 2.x i
I am thrilled to see this!
Huge thanks to INFRA team who made this possible and deployed / integrated all
new machines into the existing CI infrastructure and everybody involved in this
effort.
The nodes were donated under 3-years NetApp Targeted Sponsorship
Regards
From: Mick Semb Wever
Dat
4, at 4:59 AM, Benedict
>> mailto:bened...@apache.org>> wrote:
>>
>> I think 3.11 supported upgrade from 2.2, but I haven’t checked. I am fairly
>> sure 4.x supported upgrade from 3.0.x also.
>>
>>
>>> On 11 Dec 2024, at 12:53, Miklosovic, Stefa
Hey,
these are interesting metrics when it comes to the number of commits for an
individual like mentioned in that list you compiled, but I want to emphasize
that the way I look at it is that it really just means how big "throughput" the
project has when it comes to how many commits they can ma
ly upgrade path all things considered.
> On 11 Dec 2024, at 12:03, Miklosovic, Stefan via dev
> wrote:
>
> Hey,
>
> I want to fork the thread where we are mentioning that 2.2 -> 5.0 would be
> cool to support.
>
> I was involved in checking that offline upgrades
Hey,
I want to fork the thread where we are mentioning that 2.2 -> 5.0 would be cool
to support.
I was involved in checking that offline upgrades from 3.0 to 5.0 work and fixed
few issues along the way (1), hence I can imagine that supporting 2.2 -> 5.0
would be basically the same thing just o
can operate. 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
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 br
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 sol
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 t
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 a
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
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) https://lists.apache.org/thread/6gzyh1zhxnkz5
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 a
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 t
//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 deprecations added in
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.
__
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 link
iting
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 wer
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
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 supp
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
Net
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 keep
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
rner
where we can't release 5.2 before 5.1 or something. I would like some more
elaboration on that.
I am also very worried about ANN vector search being in jeopardy for 5.0 which
is an important feature for me to win some internal company bet 🙂
My 2 cents,
German
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
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
eventually
7;s actually the most productive path tbh.
Go slow to go fast, 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 annotati
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
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 bu
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 one
, 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 "forRe
40 matches
Mail list logo
