> 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:
>>>  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 non-deprecated features
>>>  4. 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.
> 

Reply via email to