+1
> On 17 Apr 2025, at 16:58, 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.
