Re: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 5.0-alpha2

+1 German Eichberger via dev 于2023年11月1日周三 04:58写道： > +1 > > Heck, yeah, we already tested the branch (build ourselves) and it works > great so far. > -- > *From:* Mick Semb Wever > *Sent:* Tuesday, October 31, 2023 1:43 PM > *Cc:* dev > *Subject:* [EXTERNAL] Re:

Re: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 5.0-alpha2

+1 Heck, yeah, we already tested the branch (build ourselves) and it works great so far. From: Mick Semb Wever Sent: Tuesday, October 31, 2023 1:43 PM Cc: dev Subject: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 5.0-alpha2 > The vote will be open for 72

Re: [VOTE] Release Apache Cassandra 5.0-alpha2

> 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

Re: Immediately Deprecated Code

For online upgrades we support skipping majors so long as the majors are adjacent. That is, any 4.x.z to any 5.x.z ( Is it recommended that you always first patch upgrade the .z to the latest before the major upgrade. ) For offline upgrades, we are aiming to maintain all compatibility. Take

Re: Immediately Deprecated Code

In your example 5.1 can read 4.x because 4.0 (?) is the earliest version that 5.x supports. I don't think you can upgrade directly from 3.x to 5.x without an intermediate stop at some version of 4.x can you? So when we get to 6.x we won't need the 4 -> 5 conversion code because 6 will only

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

I think the goal is to say "how could we get some working version of TCM/Accord into people's hands to try out at/by Summit?" That's all. People are eager to see it and try it out. > On Oct 31, 2023, at 12:16 PM, Benedict wrote: > > No, if I understand it correctly we’re in weird

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

No, if I understand it correctly we’re in weird hypothetical land where people are inventing new release types (“preview”) to avoid merging TCM[1] in the event we want to cut a 5.1 release from the PR prior to the summit if there’s some handful of failing tests in the PR. This may or may not be a

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

I'd add that even if we commit running CI to verify that we are not introducing new test failures, we can always inadvertently introduce new flakies. Those flakies can be hit long after the original commit, for example while trying to make a release. On Tue, 31 Oct 2023 at 17:08, Paulo Motta

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

Even if it was not formally prescribed as far as I understand, we have been following the "only merge on Green CI" custom as much as possible for the past several years. Is the proposal to relax this rule for 5.0? On Tue, Oct 31, 2023 at 1:02 PM Jeremiah Jordan wrote: > You are free to argue

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

You are free to argue validity. I am just stating what I see on the mailing list and in the wiki. We had a vote which was called passing and was not contested at that time. The vote was on a process which includes as #3 in the list: 1. Before a merge, a committer needs either a

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

That vote thread also did not reach the threshold; it was incorrectly counted, as committer votes are not binding for procedural changes. I counted at most 8 PMC +1 votes. The focus of that thread was also clearly GA releases and merges on such branches, since there was a focus on releases being

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

I never said there was a need for green CI for alpha. We do have a requirement for not merging things to trunk that have known regressions in CI. Vote here: https://lists.apache.org/thread/j34mrgcy9wrtn04nwwymgm6893h0xwo9 On Oct 31, 2023 at 3:23:48 AM, Benedict wrote: > There is no

Fwd: Upcoming Community Meetings

Today is the monthly Cassandra contributor meeting at 10:00 PT / 13:00 ET / 17:00 UTC / 22:30 IST. Piotr Kołaczkowski will share details about CEP-29: CQL Not operator and how to use and contribute. How to join:

Re: Immediately Deprecated Code

Skipping versions on upgrade is absolutely something that happens in the real world. This is particularly highlighted by the discussion around 5.0/5.1 that's been happening - 5.0 has been described as a potential "ghost version" which I completely understand. Getting rid of some of the old cruft

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

@henrik, Have you made any progress on this? I would like to help drive it forward but I am waiting to see what your code looks like and figure out what I need to do. Any update on timeline would be appreciated. On Mon, Oct 23, 2023 at 9:07 PM Jon Haddad wrote: > I think this is a great more

Re: Immediately Deprecated Code

Good point. When I was thinking about this originally I did realize that the deprecated tag would need a since = v+1 but I neglected to note that in my original post. So in your example the code would be maked as deprecated since v5.0 even though the code base it is being written in is 4.0. Thus

Re: Immediately Deprecated Code

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

Immediately Deprecated Code

I was thinking about code that is used to migrate from one version to another. For example the code that rewrote the order of the hash values used for Bloom filters. That code was necessary for the version it was coded in. But the next version does not need that code because the next version is

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

There is no requirement for green CI on alpha. We voted last year to require running all tests before commit and to require green CI for beta releases. This vote was invalid because it didn’t reach the vote floor for a procedural change but anyway is not inconsistent with knowingly and selectively