[ANNOUNCE] Apache Cassandra 4.1-beta1 test artifact available

The test build of Cassandra 4.1-beta1 is available. sha1: 5d9d93ea08d9c76402aa1d14bad54bf9ec875686 Git: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1-beta1-tentative Maven Artifacts:

Re: Shall 4.2 become 5.0 ?

Mick, Ignore me. I misread your original post. On Mon, Sep 26, 2022 at 2:01 PM Ekaterina Dimitrova wrote: > We agreed long ago to drop the JavaScript UDFs, they were already > deprecated in CASSANDRA-17280 > That was decided around Nashorn and JDK17 and there is ticket > CASSANDRA-17281 to

Re: [DISCUSS] Revising our release criteria, commit guidelines, and the role of circleci vs. ASF CI

On Mon, Sep 26, 2022 at 1:31 PM Josh McKenzie wrote: > > 250 iterations isn't enough; I use 500 as a low water mark. > > Say more here. I originally had it at 500 but neither Mick nor I knew why and > figured we could suss this out on this thread. I've seen flakies that passed with less later

Re: [DISCUSS] Revising our release criteria, commit guidelines, and the role of circleci vs. ASF CI

Happy to help! Certainly getting Circle CI and ASF CI at parity seems like a good goal. I'm going to probably have some extra cycles next week while I'm at ApacheCon, so I'm hoping to make some meaningful progress :) Cheers, Derek On Mon, Sep 26, 2022 at 12:44 PM Ekaterina Dimitrova wrote: >

Cassandra project status update 2022-09-26

/wave ApacheCon is next week! Looking forward to seeing many of you there. We should add some coverage of that to the next biweekly maybe; that could be fun. The 4.1 beta and ga releases continue to be held back by roughly 10 failing tests - often different failures on each run that can be

Re: Shall 4.2 become 5.0 ?

We agreed long ago to drop the JavaScript UDFs, they were already deprecated in CASSANDRA-17280 That was decided around Nashorn and JDK17 and there is ticket CASSANDRA-17281 to cover that effort. On Mon, 26 Sep 2022 at 14:05, Mick Semb Wever wrote: > > It's obviously still in progress, but

Re: [DISCUSS] Revising our release criteria, commit guidelines, and the role of circleci vs. ASF CI

Thanks Josh for bringing this up. I agree with Brandon on both points he made. I have also other examples of testing some things only in Jenkins or only in CircleCI. If people are fine with that, I can open a ticket and I just talked n Slack to Derek who expressed interest to help with that

Re: [DISCUSS] Revising our release criteria, commit guidelines, and the role of circleci vs. ASF CI

> 250 iterations isn't enough; I use 500 as a low water mark. Say more here. I originally had it at 500 but neither Mick nor I knew why and figured we could suss this out on this thread. > This is also assuming that circle and ASF CI run the same tests, which > is not entirely true. +1: we need

Re: [DISCUSS] Revising our release criteria, commit guidelines, and the role of circleci vs. ASF CI

On Mon, Sep 26, 2022 at 12:20 PM Josh McKenzie wrote: > For CI on a patch, run the pre-commit suite and also run multiplexer with 250 > runs on new, changed, or related tests to ensure not flaky 250 iterations isn't enough; I use 500 as a low water mark. > I think it's worth calling out:

Re: Shall 4.2 become 5.0 ?

> It's obviously still in progress, but CASSANDRA-16052 > may introduce > some breaking changes to the 2i API. > Can you elaborate Caleb? To my understanding, we do not want (and this thread is not about) permitting breaking changes from

Re: Shall 4.2 become 5.0 ?

It's obviously still in progress, but CASSANDRA-16052 may introduce some breaking changes to the 2i API. On Mon, Sep 26, 2022 at 12:45 PM Josh McKenzie wrote: > qualifies to me as “this release is not backwards compatible with 4.1”. > >

Re: Shall 4.2 become 5.0 ?

> qualifies to me as “this release is not backwards compatible with 4.1”. I'm +1 on considering dropping a specific JDK's support as being a non-backwards compatible change. On Mon, Sep 26, 2022, at 1:34 PM, Jeremiah D Jordan wrote: > If we drop Java 8 support then I would think we need to go to

Re: Shall 4.2 become 5.0 ?

> do we want to drop support in trunk for upgrading from 3.x ? This is a bit premature as it hasn't even gone to a vote yet, but if accepted, CEP-21 might make this something we want to do.

Re: Shall 4.2 become 5.0 ?

If we drop Java 8 support then I would think we need to go to 5.0. That definitely qualifies to me as “this release is not backwards compatible with 4.1”. -Jeremiah > On Sep 26, 2022, at 12:12 PM, Aleksey Yeshchenko wrote: > > Don’t have an opinion on designating 4.2 as 5.0 instead, though

[DISCUSS] Revising our release criteria, commit guidelines, and the role of circleci vs. ASF CI

Mick and I have been chatting back and forth a bit about 4.1 beta, ASF CI, circleci, and the current challenges we face as a project with our CI environment(s). Given the consistent difficulty we continue to have with the ASF CI env that's been blocking our beta + ga for months now, I think we

Re: Shall 4.2 become 5.0 ?

Don’t have an opinion on designating 4.2 as 5.0 instead, though it might be a nice idea for marketing reasons, if enough splashy features make it into it. If or when we go with 5.0 however, we don’t have to drop any compatibility with older versions just because our SemVer rules technically

Shall 4.2 become 5.0 ?

More precisely, do we want to drop anything 4.x deprecated, or do we want to drop support in trunk for upgrading from 3.x ? And are we ready to commit now to saying let trunk be 5.0 ? Our SemVer versioning rules, being operator rather than user facing, state that these compatibility concerns are

Re: Cassandra project status update 2022-09-14

> > We discussed in JIRA + ML a balanced approach to cutting 4.1 GA, which was > having 1 green run to cut beta and 3 green runs in a row to cut GA (correct > me if I'm wrong here Mick). To that end, checking in on 4.1 Butler we see > we're at 6 failures on run 162: >