> Curious what others think though. I'm +1 on the spirit of getting MVs to
> a stable point, but not convinced this is the best approach.
>
IMHO, focus should be on accord-based MVs. Even if that means it's blocked
on first adding support for multiple conditions.
.
> I’m working on updating the date in the form. Some feedback I plan to
> eventually give: it took me literally 12 hours (that’s not an
> exaggeration) to clone the ASF Infra repo (on a good internet connection)
> to make this one line change and that took the free time I had over the
> wee
27;re asking if we need a VOTE
> thread, but also saying you want one regardless of ASF policy. Am I
> understanding you correctly?
>
>
>
>
> On Mon, May 5, 2025 at 3:37 AM Mick Semb Wever wrote:
>
>> .
>>
>>
>>> This IP Clearance form is n
.
> This IP Clearance form is not yet completed. Please fill out the data
> column in the form to indicate all steps have been done.
>
Please fill out the *date* column in the form to indicate all steps have
been done.
😮💨
Apologies for coming in late on this one.
+1 in general, but… -1 on the gh transfer (see below), and a few questions
seeking clarification.
Dave, is your comment about lazy-consensus applicable to both the project's
PMC or the IPMC (Incubator PMC's role on this thread) ? My understanding
is tha
> On Tue, 29 Apr 2025 at 10:10, Benedict wrote:
>>> >
>>> > We should never download and install software via adhoc scripts
>>> without user consent. Was this ever discussed on this mailing list? If not,
>>> it’s a clear breach of policy (introducing
Our nodetool pages can definitely be improved. Each has a bare sentence
description.
I mean what can a newcomer do with
"gossipinfo - Shows the gossip information for the cluster"
An example of where any extra denseness, in this case examples of when and
why, would go a long way.
On Wed, 30
Congrats!
On Wed, 30 Apr 2025 at 13:44, Josh McKenzie wrote:
> Hey there Cassandra Devs!
>
> The Apache Cassandra PMC is very happy to announce that Jaydeep Chovatia
> has
> accepted the invitation to become a committer!
>
> Jaydeep has been busy on Cassandra for a good while now, most recently
.
> But that doesn’t seem to be the case here, the script checks for arm vs
> amd64, Linux vs Mac, and then fetches and untars the go distro into tmp.
> There is no verification of the download. The only check is if curl
> returned non 0.
>
Thanks for catching this, the sha256 check should
Welcome David!
On Mon, 28 Apr 2025 at 21:10, Jon Haddad wrote:
> Hey everyone!
>
> The Project Management Committee (PMC) for Apache Cassandra is delighted
> to announce that David Capwell has joined the PMC!
>
> Thank you David for all your contributions to the project over the years.
>
> The P
gt;> installing go.
>>>
>>> Ideally we would not pull in one more language for a small task but it’s
>>> hard for me to judge how difficult it would’ve been to implement this
>>> feature differently.
>>>
>>> On Sun, Apr 27, 2025, at 6:20 PM,
rate accord
> to ant if that’s the project preference, but there’s continual discussion
> to begin modularising Cassandra (at least a little), and a proposal to use
> grade for the modules - which might be a happy medium for everyone’s
> competing priorities.
>
>
> On 24
tion website?
>
> On Thu, Apr 24, 2025, at 8:25 AM, Mick Semb Wever wrote:
>
> Does this also apply to gradle, which now gets downloaded and installed,
> and is the most recent addition ?
>
> The python requirement from gen-doc has been around for over three years
> now.
d times when developing would be helpful.
>
> Jordan
>
> On Wed, Apr 23, 2025 at 13:37 Mick Semb Wever wrote:
>
> Python and Go are used by the gen-doc target.
>
> Code changes can break these, hence it is part of `ant check`.
> It is not called by `ant jar`
>
> If
Python and Go are used by the gen-doc target.
Code changes can break these, hence it is part of `ant check`.
It is not called by `ant jar`
If you want to run check but skip it, it's to add `-Dant.gen-doc.skip=true`
On Wed, 23 Apr 2025 at 22:06, Alex Petrov wrote:
> Hi folks,
>
> Building Cas
.
>
> This reads to me that Java 17 would need to be deprecated now, continue to
> be deprecated in 6.0 (at least one major in deprecated), then removed in
> 7.0.
>
This is technically true. But I don't think we need to be explicitly
deprecating jdk versions. Users are generally aware of J
.
> I'll plan to leave the vote open until we hit enough participation to pass
> or fail it up to probably a couple weeks.
>
+1
On Mon, 14 Apr 2025 at 10:23, Štefan Miklošovič
wrote:
> BTW If you still do not want to take care of closing it, that is also
> fine, because we have a script at least.
>
>>
>>>
Relying on the PR name seems a bit brittle. Maybe it wouldn't take much to
improve it.
e.g. would it be possible to
On Thu, 10 Apr 2025 at 22:54, Josh McKenzie wrote:
> …
> So here's what I'm thinking: a new release strategy that doesn't use
> .MINOR of semver. Goals:
> - Simplify versioning for end users
> - Provide clearer contracts for users as to what they can expect in
> releases
> - Simplify support for
gt; confuses the community imo.
>
> Jordan
>
> On Thu, Apr 10, 2025 at 12:02 Mick Semb Wever wrote:
>
>> Rather than only tackle this one-off, can we please put energy into
>> Josh's proposal raised above.
>>
>> This discussion has both technical implications
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 release, I'd
>> like to be consistent with what I call it, and have a unified voice as a
>> project.
>>
On Tue, 8 Apr 2025 at 23:59, Joel Shepherd wrote:
> FWIW, my personal experience is that mixing automated notifications
> (beyond a very low volume) with human communications adds a bunch of noise
> to the human conversations and increases the risk of an interesting
> automated notification being
Under a ASF targeted sponsorship, NetApp (Instaclustr) has been very
generous with the community and donated ten beefy (AMD EPYC 9454P Genoa
48-Core, 256G ram) servers to be used with our ci-cassandra.apache.org
infrastructure.
On each server we fit 6 jenkins executors, increasing our ci-cassandra
.
On Tue, 18 Mar 2025 at 09:13, Mick Semb Wever wrote:
> (general@incubator cc'd)
>
> Please vote on the acceptance of the Spark-Cassandra-Connector and its
> IP Clearance:
>
> https://incubator.apache.org/ip-clearance/cassandra-spark-cassandra-connector.html
>
(general@incubator cc'd)
Please vote on the acceptance of the Spark-Cassandra-Connector and its
IP Clearance:
https://incubator.apache.org/ip-clearance/cassandra-spark-cassandra-connector.html
All consent from original authors of the donation, and tracking of
collected CLAs, is found in
https://g
.
PMC members, please check carefully the IP Clearance requirements before
> voting.
>
> The vote will be open for 72 hours (or longer). Votes by PMC members
> are considered binding. A vote passes if there are at least three
> binding +1s and no -1's.
>
+1
Vote passes with twelve +1s (ten binding).
> On Sun, Mar 9, 2025 at 5:18 AM Mick Semb Wever wrote:
>>>
>>>> Please vote on the acceptance of the Cassandra Cluster Manager (CCM)
>>>> and its IP Clearance:
>>>> https://incubator.apache.org/ip-cl
.
> The vote will be open for 72 hours (or longer). Votes by PMC members
> are considered binding. A vote passes if there are at least three
> binding +1s and no -1's.
+1
Please vote on the acceptance of the Cassandra Cluster Manager (CCM)
and its IP Clearance:
https://incubator.apache.org/ip-clearance/cassandra-ccm.html
All consent from original authors of the donation, and tracking of
collected CLAs, is found in:
- https://github.com/riptano/ccm/issues/773
-
h
The IPMC vote only requires lazy consensus on IP Clearance matters.
> Detailed in:
> https://incubator.apache.org/ip-clearance/
That's correct, the vote is directed to the Cassandra PMC. The IPMC is
only cc'd for notification, as is required.
On Thu, 6 Mar 2025 at 09:40, Štefan Miklošovič
wrote:
> That is cool but this still does not show / explain how it would look like
> when it comes to dependencies needed for actually talking to storages like
> s3.
>
As Benedict writes, dealing with optional dependencies is not hard (and as
Jon
Congrats Bernardo!
On Wed, 5 Mar 2025 at 16:03, Abe Ratnofsky wrote:
> Congratulations Bernardo! Great news.
>
Well deserved Aaron ! 🎉
On Tue, 4 Mar 2025 at 19:27, Jon Haddad wrote:
>
> Congrats Aaron!
>
> On Tue, Mar 4, 2025 at 10:26 AM Jordan West wrote:
>>
>> Congratulations!!
>> On Tue, Mar 4, 2025 at 09:57 Tolbert, Andy wrote:
>>>
>>> Congrats Aaron!
>>>
>>> On Tue, Mar 4, 2025 at 11:24 AM Francis
.
It’s not an area where I can currently dedicate engineering effort. But if
> others are interested in contributing a feature like this, I’d see it as
> valuable for the project and would be happy to collaborate on
> design/architecture/goals.
>
Jake mentioned 17 months ago a custom FileSys
.
> The Project Management Committee (PMC) for Apache Cassandra is delighted to
> announce that Ekaterina Dimitrova has joined the PMC!
>
> Thanks a lot, Ekaterina, for everything you have done for the project all
> these years.
Congrats Ekaterina !
.
>
> Please join us in welcoming Caleb to his new role!
>
Congratulations Caleb !!
There have been no objections after 9 days. I'll commit these changes also
to 5.0
On Tue, 11 Feb 2025 at 11:16, Jon Haddad wrote:
> +1 to putting it in 5.0
>
>
> On Tue, Feb 11, 2025 at 2:10 AM Mick Semb Wever wrote:
>
>> Any objections to making the fol
Solid write up Jon!
Hoping the committers and PMC members are keeping in mind this (very)
recent thread: https://lists.apache.org/thread/h38g6q9d8h1q92h6qzs5tqdxpn2vmnyy
This thread needs to also be about evaluating the risk these commits
are to a patch version.
I'm +1 and here's my thinking over
.
> I hope you will join me in welcoming him to the committee.
Welcome JD!
On Tue, 11 Feb 2025 at 19:56, Caleb Rackliffe
wrote:
> When we add IS [NOT] NULL support, that would preferably NOT match EMPTY
> values for the types where empty means something, like strings. For
> everything else, EMPTY could be equivalent to null and match IS NULL.
>
Makes sense to me to sa
Any objections to making the following changes also to 5.0 ?
CASSANDRA-20296 proposes the following changes:
1. G1 to by default use `-XX:G1NewSizePercent=50` to floor the young
generation's size to 50% of the heap. (We know in production this can
often be raised to 66% for optimal performance.)
.
> The vote will be open for 24 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.
The vote has passed with three binding +1s and no vetoes.
.
> The vote will be open for 24 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
- so
Proposing the test build of Cassandra 4.0.17 for release.
sha1: 0354c915a9f8be6ab671af5ff93b8178e6f2e76f
Git: https://github.com/apache/cassandra/tree/4.0.17-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1363/org/apache/cassandra/cassandra-all/4.0
.
> The vote will be open for 24 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
- so
.
> The vote will be open for 24 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
-
+1 :-)
On Wed, 5 Feb 2025 at 23:05, Blake Eggleston wrote:
> Ok ok, I've jumped gun here, sorry, small off by 24 error. Please continue
> voting, and I'll be back tomorrow :D
>
> On Wed, Feb 5, 2025, at 1:49 PM, Blake Eggleston wrote:
>
> The vote passes with 10 +1s (4 nb) and no -1.
>
> Thanks
.
> If you mean only 4.1 and 5.0 would be online upgrade targets, I would
> suggest we change that to T-3 so you encompass all “currently supported”
> releases at the time the new branch is GAed.
>
> I think that's better actually, yeah. I was originally thinking T-2 from
> the "what calendar
.
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 correct
- source a
.
> 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
- s
.
> 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
- so
replies inline…
.
We have far fewer (and more effective?) JVM Upgrade DTests.
> There we only need 8x medium (3 cpu, 5GB ram) servers
>
> Does anyone have a strong understanding of the coverage and value offered
> by the python upgrade dtests vs. the in-jvm dtests? I don't, but I
> intuitively h
.
> 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
- sou
.
>
> 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
Jordan, replies inline.
To take a snippet from your email "A little empathy for our users goes a
> long way." While I agree clarity is important, forcing our users to
> upgrade multiple times is not in their best interest.
>
Yes – we would be moving in that direction by now saying we aim for o
There's still a few open loops in this thread that I'd like to keep pushing
on.
I admit I've been pretty adamant that there's real value for a) users,
operators, and ourselves, having an intuitive understanding of our
recommended upgrade paths by versions, and b) a method to reduce the CI
testing
I think the status quo here extends to: operational issues and
performance regressions can be considered like bugs in this context,
and patches that are very isolated and deemed safe by any pmc member
with experience in that area of the code can approve it on the ticket
without it going to the mail
On Mon, 20 Jan 2025 at 02:16, Jeff Jirsa wrote:
> IIRC Cassandra is configured such that only PMC members can roll a release
>
FTR, it's only the very final step of pushing the release artefacts public
that only the PMC can do. Any committer can initiate and lead the release
process at large.
On Thu, 16 Jan 2025 at 22:06, Caleb Rackliffe
wrote:
> …
> There are forks out there, of course, and they would be affected, too.
>
This. Let's make sure to check thoroughly, this could really hurt people
(for what is a trivial annoyance).
Personally, braces on newlines doesn't bother me. I
Jumping in, I'm ok to allow it in tests for a trial period too. I would
imagine in test methods especially it's of much less concern, where the
code is much simpler to read, and also safer to change to types later on.
On Wed, 8 Jan 2025 at 16:46, Josh McKenzie wrote:
> I would like to remove th
On Fri, 13 Dec 2024 at 06:06, Jeremiah Jordan
wrote:
> TL;DR - in progress migration off 2.2 to 5.0 is annoying as there were
>>> different bugs in the past we have to support again. Out of process
>>> migration to me feels far more plausible, but feels annoying without
>>> splitting off our rea
I know a few teams on 2.2 that would *love* to be able to jump right to
> 5.0. Once you fall far enough behind, upgrading to another version that's
> already deprecated becomes paralyzing. I don't expect 2.2 compatibility
> btw, just using it as an example.
>
> If it can be done, it would make a
I would very much rather keep our upgrade paths simple and intuitive:
You can only upgrade between adjacent major versions.
This does catch users, and keeping it simple has helped a lot.
I find it helps internally working on the code too, with a focus on
stability for online upgrades, which does q
> A possibility with SAI is to mark it beta while also marking 2i as
> deprecated (and leaving SASI as marked). This sends a clear signal
> (imho) that SAI is the recommended solution forward but also being
> honest about its maturity and QA.
(and leaving SASI as marked *experimental*)
I see value in using a beta flag in addition to an experimental flag,
and that such a beta flag should see a lot more use than experimental.
Java 17 definitely falls in the beta category. I/We definitely
recommend its usage in production, but as has been said data is needed
over trust and the co
Chiming in with my two cents…
When people have the luxury of working in environments where clusters are
> massively over provisioned, LCS as a default makes a lot of sense, because
> there's not much downside. The use cases where you'd actually fall behind
> in compaction are pretty slim, so the
+1 for more code (github/ide) readable in-code documentation.
Do we use javadoc anywhere anymore, or read its generated apidocs
anywhere ? We removed that target from the build cycle, and don't
publish those artefacts or deploy the apidocs anywhere anymore… I
would say folk are either got the c
On Sat, 16 Nov 2024 at 00:18, Caleb Rackliffe
wrote:
> The subject line probably says it all, but just to confirm, we won't be
> supporting 3.11 -> 5.1/trunk upgrades, correct?
>
Correct. To be specific, online upgrades.
> If that's correct, I'm going to go ahead and remove v30 and v3X from
>
>
> 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
- sourc
As per the CEP process documentation, this vote will be open for 72 hours
> (longer if needed).
>
+1
Can you please put the ticket description in the email. Saves us having to
follow the link to know what you're talking about.
Yes to backporting this.
On Tue, 5 Nov 2024 at 10:27, Štefan Miklošovič
wrote:
> Hello,
>
> I want to ask if there are objections for backporting CASSANDRA-17812 (1)
>
Thanks Jaydeep. I've exhausted my lines on enquiry and am happy that
thought has gone into them.
> On top of the above list, here is my recommendation (this is just a pure
> thought only and subject to change depending on how all the community
> members see it):
>
>- Nov-Dec: We can definit
Jaydeep,
your replies address my main concerns, there's a few questions of
curiosity as replies inline below…
> >Without any per-table scheduling and history (IIUC) a node would have
> to restart the repairs for all keyspaces and tables.
>
> The above-mentioned quote should work fine and wi
any name works for me, Jaydeep :-)
I've taken a run through of the CEP, design doc, and current PR. Below are
my four (rough categories of) questions.
I am keen to see a MVP land, so I'm more looking at what the CEP's design
might not be able to do, rather than what may or may not land in an init
On Wed, 23 Oct 2024 at 05:48, Jordan West wrote:
> Josh/Mick, where does that leave us? I’d like to start with the smaller
> scope Josh described in his last email. We can tackle in-tree/stress
> separately.
>
> I was going to start working on getting signed ICLAs. Does that still
> sound like th
The Cassandra team is pleased to announce the release of Apache Cassandra
version 5.0.2.
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 an
>
> Isn't it weird that you said that we should not save characters at the
> cost of readability while we just use CASS everywhere except the main
> project? Why do you think that having "CASS-" will make people
> automatically think that this is Cassandra related. No other project in
> Apache (afa
Vote passes with six +1s (four binding) and no vetoes.
ref: https://lists.apache.org/thread/wb8k7t0vfpj5hs4k7h2gydbkl8qmlsqz
On Wed, 16 Oct 2024 at 14:18, Mick Semb Wever wrote:
> Proposing the test build of Cassandra 5.0.2 for release.
>
> sha1: f278f6774fc76465c182041e081982105c3e7
This is looking strong, thanks Jaydeep.
I would suggest folk take a look at the design doc and the PR in the CEP.
A lot is there (that I have completely missed).
I would especially ask all authors of prior art (Reaper, DSE nodesync,
ecchronos) to take a final review of the proposal
Jaydeep, can
;> >>> Kind Regards,
>>>>> > >> >>> Brandon
>>>>> > >> >>>
>>>>> > >> >>> On Wed, Oct 2, 2024 at 5:07 PM Brandon Williams <
>>>>> dri...@gmail.com>
>>&g
reply below.
> 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 correct
- s
Proposing the test build of Cassandra 5.0.2 for release.
sha1: f278f6774fc76465c182041e081982105c3e7dbb
Git: https://github.com/apache/cassandra/tree/5.0.2-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1349/org/apache/cassandra/cassandra-all/5.0.2
arg parsing alone is a
> 5K line mess. It's certainly not being well-maintained and could use a
> replacement.
>
> On Sun, Oct 13, 2024 at 10:25 PM Josh McKenzie
> wrote:
>
>
> Unsolicited .02:
>
> - If this will eventually replace the in-tree cassandra-stress, does i
The test build of Cassandra 5.0.2 is available.
sha1: f278f6774fc76465c182041e081982105c3e7dbb
Git: https://github.com/apache/cassandra/tree/5.0.2-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1349/org/apache/cassandra/cassandra-all/5.0.2/
The So
I'll start a 5.0.2 release then…
unless there's anything else in-flight I should be waiting for …?
On Fri, 11 Oct 2024 at 23:06, Caleb Rackliffe
wrote:
> Just to close the loop, this is committed to 5.0 and trunk.
>
> On Wed, Oct 9, 2024 at 3:07 PM Caleb Rackliffe
> wrote:
>
>> Hey folks,
>>
reply below.
> I’m terms of next steps: Mick what do we need to do next? Figure out the
> answers to your questions re: getting contributor sign off?
>
The process of donation is as follows… (feel free to correct me, or add
anything)
1. General pre-agreement from the PMC that we'll take this
To play devil's advocate here, it's important that the subprojects don't
lose visibility and silo from the rest of the project.
There are different ways to solve this, and lumping everything into one
jira project is a messy and poor way of doing it. But as the sidecar has
shown us, subproject act
The Cassandra team is pleased to announce the release of Apache Cassandra
version 5.0.1.
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 an
Agree with Jon, Josh and Patrick here.
This is the type of hidden subproject that will get us into trouble with
the board/foundation. I'm sure it's getting enough committer eyeballs,
and some PMC oversight, but maybe not enough. Addressing the more material
points that Jon mentions is the best
.
Proposing the test build of Cassandra 5.0.1 for release.
>
> sha1: c206e4509003ac4cd99147d821bd4b5d23bdf5e8
> Git: https://github.com/apache/cassandra/tree/5.0.1-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1348/org/apache/cassandra/cassand
The Cassandra team is pleased to announce the release of Apache Cassandra
version 4.1.7.
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 an
The Cassandra team is pleased to announce the release of Apache Cassandra
version 4.0.14.
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 a
Vote passes with five +1s, four binding.
ref: https://lists.apache.org/thread/clq6959ntgltbpzx21xl1jkphcowwgg7
On Fri, 20 Sept 2024 at 16:35, Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 4.1.7 for release.
>
> sha1: ca494526025a480bc8530ed3ae472ce8c9cbaf7a
Vote passes with three binding +1s
ref: https://lists.apache.org/thread/lps6bskc1lr8f5bfhglystcmjdnqzn24
On Fri, 20 Sept 2024 at 16:35, Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 4.0.14 for release.
>
> sha1: 7bf67349579411521bcdee4febd209cff63179a6
.
>
> The vote will be open for 96 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 correct
- source ar
.
>
> The vote will be open for 96 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
- sour
.
>
> The vote will be open for 96 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
Proposing the test build of Cassandra 5.0.1 for release.
sha1: c206e4509003ac4cd99147d821bd4b5d23bdf5e8
Git: https://github.com/apache/cassandra/tree/5.0.1-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1348/org/apache/cassandra/cassandra-all/5.0.1
Proposing the test build of Cassandra 4.1.7 for release.
sha1: ca494526025a480bc8530ed3ae472ce8c9cbaf7a
Git: https://github.com/apache/cassandra/tree/4.1.7-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1347/org/apache/cassandra/cassandra-all/4.1.7
Proposing the test build of Cassandra 4.0.14 for release.
sha1: 7bf67349579411521bcdee4febd209cff63179a6
Git: https://github.com/apache/cassandra/tree/4.0.14-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1345/org/apache/cassandra/cassandra-all/4.0
1 - 100 of 1015 matches
Mail list logo
