Re: [VOTE] Simplifying our release versioning process

[Benedict]

+1 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. 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 poorly supported (first or third party) feature to justify breaking an API. I’d be happy to strengthen our guidance on this to facilitate future DISCUSS threads. On 18 Apr 2025, at 13:44, Josh McKenzie <jmcken...@apache.org> wrote:  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-breaking changes. Or additions for that matter (I believe we already agreed on the latter). On Thu, Apr 17, 2025, at 5:38 PM, C. Scott Andreas wrote: +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:32 PM, Nate McCall <zznat...@gmail.com> wrote: +1 On Fri, 18 Apr 2025 at 3:59 AM, Josh McKenzie <jmcken...@apache.org> 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 time of new .MAJOR T-1 releases are guaranteed API compatible for non-deprecated features We use a deprecate-then-remove strategy for API breaking changes (deprecate in release N, then remove in N+1) This would translate into the following for our upcoming releases (assuming 3 supported majors at all times): 6.0: 5.0, 4.1, 4.0 online upgrades are supported (grandfather window). We drop support for 4.0. API compatibility is guaranteed w/5.0 7.0: 6.0, 5.0, 4.1 online upgrades are supported (grandfather window). We drop support for 4.1. API compatibility is guaranteed w/6.0 8.0: 7.0, 6.0, 5.0 online upgrades are supported (fully on new paradigm). We drop support for 5.0. API compatibility guaranteed w/7.0 David asked the question: Does this imply that each release is allowed to make breaking changes (assuming they followed the “correct” deprecation process)? My first instinct is to not like this Each release would be allowed to make breaking changes but only for features that have already been deprecated for one major release cycle. This is a process change so as per our governance: https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Project+Governance, it'll require a super majority of 50% of the roll called PMC in favor. Current roll call is 21 so we need 11 pmc members to participate, 8 of which are in favor of the change. I'll plan to leave the vote open until we hit enough participation to pass or fail it up to probably a couple weeks.