+1
> On Apr 22, 2025, at 7:20 PM, Joseph Lynch <joe.e.ly...@gmail.com> 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 Josh's proposal is merely "We use a deprecate-then-remove strategy
> for API breaking changes (deprecate in release N, then remove in N+1)" and I
> don't see anything in the linked Governance page referring to this discuss
> policy on breaking changes.
>
> 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?
>
> -Joey
>
> On Tue, Apr 22, 2025 at 6:17 PM Patrick McFadin <pmcfa...@gmail.com
> <mailto:pmcfa...@gmail.com>> wrote:
>> +1
>>
>> On Tue, Apr 22, 2025 at 8:52 AM Dmitry Konstantinov <netud...@gmail.com
>> <mailto:netud...@gmail.com>> wrote:
>>> +1
>>>
>>> On Tue, 22 Apr 2025 at 16:37, Caleb Rackliffe <calebrackli...@gmail.com
>>> <mailto:calebrackli...@gmail.com>> wrote:
>>>> +1
>>>>
>>>> On Tue, Apr 22, 2025 at 8:37 AM Ekaterina Dimitrova <e.dimitr...@gmail.com
>>>> <mailto:e.dimitr...@gmail.com>> 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 <s...@beobal.com
>>>>> <mailto:s...@beobal.com>> wrote:
>>>>>> +1
>>>>>>
>>>>>> > On 17 Apr 2025, at 16:58, Josh McKenzie <jmcken...@apache.org
>>>>>> > <mailto: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.
>>>>>>
>>>>>>
>>>
>>>
>>>
>>> --
>>> Dmitry Konstantinov
