> With the publication of this release I would like to switch the
> default 'latest' docs on the website from 4.1 to 5.0. Are there any
> objections to this ?
I would also like to propose the next 5.0 release to be 5.0-beta1
With the aim of reaching GA for the Summit, I would like to suggest
1. “No objections from me since these issues are mostly cosmetic, but it
would be nice to clear these before the next alpha/beta. I will create a
ticket for the unknown module warning later if nobody beats me to it.”
1.
1. CASSANDRA-19001
Nice, thanks for the quick fix! Checked and working now.
On Sat, 4 Nov 2023 at 21:11 Mick Semb Wever wrote:
>
>
> On Sun, 5 Nov 2023 at 00:49, Paulo Motta wrote:
>
>> > With the publication of this release I would like to switch the
>> default 'latest' docs on the website from 4.1 to 5.0.
I agree and just now opened it for 5.0-beta (among others.)
Kind Regards,
Brandon
On Sat, Nov 4, 2023 at 11:08 AM Benedict wrote:
>
> I think before we cut a beta we need to have diagnosed and fixed 18993
> (assuming it is a bug).
>
> > On 4 Nov 2023, at 16:04, Mick Semb Wever wrote:
> >
> >
Yep, data loss bugs are not any old bug. I’m concretely -1 (binding) releasing a beta with one that’s either under investigation or confirmed.As Scott says, hopefully it won’t come to that - the joy of deterministic testing is this should be straightforward to triage.On 4 Nov 2023, at 17:30, C.
On Sun, 5 Nov 2023 at 00:49, Paulo Motta wrote:
> > With the publication of this release I would like to switch the default
> 'latest' docs on the website from 4.1 to 5.0. Are there any objections to
> this ?
>
> It looks like the switch of latest to 5.0 broken some top search links
> (returns
I’d happily be the first to vote -1(nb) on a release containing a known and reproducible bug that can result in data loss or an incorrect response to a query. And I certainly wouldn’t run it.Since we have a programmatic repro within just a few seconds, this should not take long to root-cause.On
Please mark such bugs with fixVersion 5.0-beta
If there are no more tickets that need API changes (i.e. those that should
be marked fixVersion 5.0-alpha) this then indicates we do not need a
5.0-alpha3 release and can focus towards 5.0-beta1 (regardless of having
blockers open to it).
Appreciate
I think before we cut a beta we need to have diagnosed and fixed 18993
(assuming it is a bug).
> On 4 Nov 2023, at 16:04, Mick Semb Wever wrote:
>
>
>>
>> With the publication of this release I would like to switch the
>> default 'latest' docs on the website from 4.1 to 5.0. Are there any
Alex can confirm but I think it actually turns out to be a new bug in 5.0, but
either way we should not cut a release with such a serious potential known
issue.
> On 4 Nov 2023, at 16:18, J. D. Jordan wrote:
>
> Sounds like 18993 is not a regression in 5.0? But present in 4.1 as well?
> So
> With the publication of this release I would like to switch the default
'latest' docs on the website from 4.1 to 5.0. Are there any objections to
this ?
It looks like the switch of latest to 5.0 broken some top search links
(returns 404 to me):
[1] -
Totally agree with the others. Such an issue on its own should be a
priority in any release. Looking forward to the reproduction test mentioned
on the ticket.
Thanks to Alex for his work on harry!
On Sat, 4 Nov 2023 at 12:47, Benedict wrote:
> Alex can confirm but I think it actually turns out
The Cassandra team is pleased to announce the release of
Apache Cassandra version 5.0-alpha2.
This release contains Vector Similarity Search (CEP-30).
http://cassandra.apache.org/
Downloads of source and binary distributions are listed in our download section:
> I think before we cut a beta we need to have diagnosed and fixed 18993
> (assuming it is a bug).
Before a beta? I could see that for rc or GA definitely, but having a known
(especially non-regressive) data loss bug in a beta seems like it's compatible
with the guarantees we're providing for
Sounds like 18993 is not a regression in 5.0? But present in 4.1 as well? So I
would say we should fix it with the highest priority and get a new 4.1.x
released. Blocking 5.0 beta voting is a secondary issue to me if we have a
“data not being returned” issue in an existing release?
> On Nov
>
> > As this is alpha release - can we open a ticket to be resolved in the
> next alpha/beta? It is up to PMC to decide, of course.
>
> No objections from me since these issues are mostly cosmetic, but it would
> be nice to clear these before the next alpha/beta. I will create a ticket
> for the
> 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.
The vote passes with 6 +1s (three binding).
With the publication
17 matches
Mail list logo
