Re: [VOTE] Simplifying our release versioning process

To close the loop here, I've updated our "Patching, release versioning, and LTS releases " wiki article with the agreed upon text here. I added the following clarification from the consensu

Re: [VOTE] Simplifying our release versioning process

On Wed, Apr 23, 2025 at 21:04 Joseph Lynch wrote: > Isn't the JDK we build with when publishing to maven somewhat of a public > interface due to cassandra-all library usage? I agree that we probably just > need to clearly document what JVMs we test a release on which is a good > signal for what w

[RESULT][VOTE] Simplifying our release versioning process

It's been 7 days and I think we have a clear consensus w/some good follow up action items. Vote results: • Binding: 16 in favor (roll call: 21) • Non-binding: 5 in favor • Dissent: none Follow ups: • Enshrine this agreed upon procedural text in our wiki w/link to discussion and vote threads

Re: [VOTE] Simplifying our release versioning process

I propose we:- Exclude JDK support from the subject of this vote.- And start a separate [DISCUSS] and [VOTE] thread to cover JDK/JRE lifecycle.Josh’s proposal that we are voting on does not address JDK versioning, and I don’t interpret the text of the proposal as a referendum on it. Many / most did

Re: [VOTE] Simplifying our release versioning process

Isn't the JDK we build with when publishing to maven somewhat of a public interface due to cassandra-all library usage? I agree that we probably just need to clearly document what JVMs we test a release on which is a good signal for what we think will work at runtime (and this may be a much newer J

Re: [VOTE] Simplifying our release versioning process

Pragmatically, I believe our in-jvm upgrade dtests require the 2 versions of C* you're testing to both support running on (and probably right now building on) a shared JDK version. So for instance, if we had: - Release 21.0.0: JDK30, JDK31 - Release 22.0.0: JDK35, JDK40 We wouldn't be able to t

Re: [VOTE] Simplifying our release versioning process

> Also, I thought we had separate discussion about them - that we want to keep > up possibly with the last two LTS versions. This is what I remember as well. 6.0 would support 17/21 as thats the latest, if 7.0 is out before 25, then 7.0 would be 17/21, else it would be 21/25 > On Apr 23, 2025,

Re: [VOTE] Simplifying our release versioning process

> The JVM version also isn’t a feature to deprecate, technically. I agree with this. I think the JVM version the server runs under and how we cycle those is a separate discussion from feature deprecation. There can and has been some overlap there that would need to be handled on a case by case ba

Re: [VOTE] Simplifying our release versioning process

I should say that I also haven’t thought of JDK versions when I voted here. Also, I thought we had separate discussion about them - that we want to keep up possibly with the last two LTS versions. Currently we do not have vision on when will be the next release date, so I cannot personally align JD

Re: [VOTE] Simplifying our release versioning process

I agree with Jon that I’m now a bit confused on part of what I voted for. It feels like there is more discussion to be had here. Or we need to split it into two votes if we want to make progress on the part where there is consensus and revisit where there is not. Regarding JVM version what I’ve mo

Re: [VOTE] Simplifying our release versioning process

> If 5.0 supports 17, then 7.0 should too, if we are to say we support 5.0 to 7.0 upgrades. I have to disagree with this. I don't see a good reason have a tight coupling of JVM versions to C* versions, and I also don't see a good reason to overlap outside of CI. Even on CI, the reasoning is a

Re: [VOTE] Simplifying our release versioning process

. > > 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

Re: [VOTE] Simplifying our release versioning process

Have it for *at least* 1 MAJOR in deprecated status (deprecate-then-remove) 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. On Wed, Apr 23, 2025 at 10:54 AM Ekaterina Dimitrova wrote: > I

Re: [VOTE] Simplifying our release versioning process

I think there is no reason to deprecate 17 in 5.0? I’d think we would deprecate at some point 11 in 5.0, (once the community is confident in 17 being prod ready.) We commit 21 in 6.0 with the plan to remove 11 and switch to 17 builds in 6.0. Any other thoughts? Points of view? On Wed, 23 Apr 202

Re: [VOTE] Simplifying our release versioning process

So to be clear - are we simultaneously calling Java 17 in 5.0 deprecated AND experimental? On Wed, Apr 23, 2025 at 10:23 AM Joseph Lynch wrote: > +1 given "Have it for *at least* 1 MAJOR in deprecated status > (deprecate-then-remove)" > > How does that sit with you Joey? >> > Great! Really app

Re: [VOTE] Simplifying our release versioning process

+1 given "Have it for *at least* 1 MAJOR in deprecated status (deprecate-then-remove)" How does that sit with you Joey? > Great! Really appreciate the clarification! -Joey

Re: [VOTE] Simplifying our release versioning process

> Can we just remove the parenthetical in #4 or clarify that breaking changes > require a minimum duration as determined by a DISCUSS thread - not to be > shorter than 1 major release? The text we're voting on right now leaves us flexible on: 1. What we decide to "API Break" 2. How we decide to

Re: [VOTE] Simplifying our release versioning process

+1 > On Apr 22, 2025, at 7:20 PM, Joseph Lynch wrote: > > I'm unclear if Josh/Ekaterina/Benedict's statements are part of the vote > amending our project governance. If consensus is required for breaking > changes with a strong preference for not breaking I am +1, but the original > text of J

Re: [VOTE] Simplifying our release versioning process

I'm unclear if Josh/Ekaterina/Benedict's statements are part of the vote amending our project governance. If consensus is required for breaking changes with a strong preference for not breaking I am +1, but the original text of Josh's proposal is merely "We use a deprecate-then-remove strategy for

Re: [VOTE] Simplifying our release versioning process

+1 On Tue, Apr 22, 2025 at 8:52 AM Dmitry Konstantinov wrote: > +1 > > On Tue, 22 Apr 2025 at 16:37, Caleb Rackliffe > wrote: > >> +1 >> >> On Tue, Apr 22, 2025 at 8:37 AM Ekaterina Dimitrova < >> e.dimitr...@gmail.com> wrote: >> >>> +1 >>> >>> I also remember we agreed on Discuss thread for re

Re: [VOTE] Simplifying our release versioning process

+1 On Tue, 22 Apr 2025 at 16:37, Caleb Rackliffe wrote: > +1 > > On Tue, Apr 22, 2025 at 8:37 AM Ekaterina Dimitrova > wrote: > >> +1 >> >> I also remember we agreed on Discuss thread for removing anything plus >> preference for backward compatibility wherever it is possible. >> >> On Tue, 22 A

Re: [VOTE] Simplifying our release versioning process

+1 On Tue, Apr 22, 2025 at 8:37 AM Ekaterina Dimitrova wrote: > +1 > > I also remember we agreed on Discuss thread for removing anything plus > preference for backward compatibility wherever it is possible. > > On Tue, 22 Apr 2025 at 7:00, Sam Tunnicliffe wrote: > >> +1 >> >> > On 17 Apr 2025,

Re: [VOTE] Simplifying our release versioning process

+1 I also remember we agreed on Discuss thread for removing anything plus preference for backward compatibility wherever it is possible. On Tue, 22 Apr 2025 at 7:00, Sam Tunnicliffe wrote: > +1 > > > On 17 Apr 2025, at 16:58, Josh McKenzie wrote: > > > > [DISCUSS] thread: > https://lists.apach

Re: [VOTE] Simplifying our release versioning process

+1 > On 17 Apr 2025, at 16:58, Josh McKenzie wrote: > > [DISCUSS] thread: > https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq > > The proposed new versioning mechanism: > • We no longer use semver .MINOR > • Online upgrades are supported for all GA supported releases at

Re: [VOTE] Simplifying our release versioning process

+1 > On 22 Apr 2025, at 10:33, Sylvain Lebresne wrote: > > +1 > -- > Sylvain > > > On Tue, Apr 22, 2025 at 10:47 AM Maxim Muzafarov > wrote: >> Also +1 >> >> On Tue, 22 Apr 2025 at 07:57, guo Maxwell > > wrote: >> >> >> >> We have alread

Re: [VOTE] Simplifying our release versioning process

+1 -- Sylvain On Tue, Apr 22, 2025 at 10:47 AM Maxim Muzafarov wrote: > Also +1 > > On Tue, 22 Apr 2025 at 07:57, guo Maxwell wrote: > >> > >> We have already agreed some time ago that any incompatible API change > requires a DISCUSS thread. I’m fairly sure it’s documented on the wiki. > > > >

Re: [VOTE] Simplifying our release versioning process

Also +1 On Tue, 22 Apr 2025 at 07:57, guo Maxwell wrote: >> >> We have already agreed some time ago that any incompatible API change >> requires a DISCUSS thread. I’m fairly sure it’s documented on the wiki. > > > Yes, I remembered that we already have a thread to reach consensus on this. > > +1

Re: [VOTE] Simplifying our release versioning process

> > We have already agreed some time ago that any incompatible API change > requires a DISCUSS thread. I’m fairly sure it’s documented on the wiki. Yes, I remembered that we already have a thread to reach consensus on this. +1 on this vote. Mick Semb Wever 于2025年4月22日周二 13:35写道： > > . > >

Re: [VOTE] Simplifying our release versioning process

. > 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

Re: [VOTE] Simplifying our release versioning process

> I'd like to maintain a *very* high bar for user API-breaking changes – much > higher than "our rules allow us to" I don't know if we've formalized this (or even need to; may be obvious?), but having a bar of "[DISCUSS] thread on dev ML with clear consensus" seems reasonable for user API-breaki

Re: [VOTE] Simplifying our release versioning process

+1We have already agreed some time ago that any incompatible API change requires a DISCUSS thread. I’m fairly sure it’s documented on the wiki.I agree with Scott: our norm should be NOT breaking things. There should be strong justification in terms of either development friction or an unsafe or poo

Re: [VOTE] Simplifying our release versioning process

+1 On Fri, 18 Apr 2025 at 3:59 AM, Josh McKenzie wrote: > [DISCUSS] thread: > https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq > > The proposed new versioning mechanism: > >1. We no longer use semver .MINOR >2. Online upgrades are supported for all GA supported releases a

Re: [VOTE] Simplifying our release versioning process

+1 To the point on breaking changes and deprecations, I'd like to maintain a *very* high bar for user API-breaking changes – much higher than "our rules allow us to". Any time we break users, the project loses release uptake and creates friction for the community. – Scott On Apr 17, 2025, at 2:

Re: [VOTE] Simplifying our release versioning process

+1 On Thu, Apr 17, 2025 at 12:14 Jeremiah Jordan wrote: > +1 > > On Apr 17, 2025 at 10:58:24 AM, Josh McKenzie > wrote: > >> [DISCUSS] thread: >> https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq >> >> The proposed new versioning mechanism: >> >>1. We no longer use semver .MI

Re: [VOTE] Simplifying our release versioning process

+1 On Apr 17, 2025 at 10:58:24 AM, Josh McKenzie wrote: > [DISCUSS] thread: > https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq > > The proposed new versioning mechanism: > >1. We no longer use semver .MINOR >2. Online upgrades are supported for all GA supported releases

Re: [VOTE] Simplifying our release versioning process

I would like to get a better understanding of "but only for features that have already been deprecated for one major release cycle." Does it mean that one has to flag a feature as deprecated in the unreleased version N, wait until when N is released (deprecating for one major cycle), and then fina

Re: [VOTE] Simplifying our release versioning process

+1 Kind Regards, Brandon On Thu, Apr 17, 2025 at 10:59 AM Josh McKenzie wrote: > > [DISCUSS] thread: > https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq > > The proposed new versioning mechanism: > > We no longer use semver .MINOR > Online upgrades are supported for all GA suppor

Re: [VOTE] Simplifying our release versioning process

+1 > On Apr 17, 2025, at 9:22 AM, Jon Haddad wrote: > > +1 > > On Thu, Apr 17, 2025 at 9:15 AM Josh McKenzie > wrote: >> +1 >> >> On Thu, Apr 17, 2025, at 11:58 AM, Josh McKenzie wrote: >>> [DISCUSS] thread: >>> https://lists.apache.org/thread/jy6vodbkh64plhdfwqz

Re: [VOTE] Simplifying our release versioning process

+1 On Thu, Apr 17, 2025 at 9:15 AM Josh McKenzie wrote: > +1 > > On Thu, Apr 17, 2025, at 11:58 AM, Josh McKenzie wrote: > > [DISCUSS] thread: > https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq > > The proposed new versioning mechanism: > >1. We no longer use semver .MINOR >

Re: [VOTE] Simplifying our release versioning process

+1 On Thu, Apr 17, 2025, at 11:58 AM, Josh McKenzie wrote: > [DISCUSS] thread: > https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq > > The proposed new versioning mechanism: > 1. We no longer use semver .MINOR > 2. Online upgrades are supported for all GA supported releases at t

[VOTE] Simplifying our release versioning process

[DISCUSS] thread: https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq The proposed new versioning mechanism: 1. We no longer use semver .MINOR 2. Online upgrades are supported for all GA supported releases at time of new .MAJOR 3. T-1 releases are guaranteed API compatible for no