+1

On Tue, 22 Apr 2025 at 16:37, Caleb Rackliffe <calebrackli...@gmail.com>
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 removing anything plus
>> preference for backward compatibility wherever it is possible.
>>
>> On Tue, 22 Apr 2025 at 7:00, Sam Tunnicliffe <s...@beobal.com> wrote:
>>
>>> +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.
>>>
>>>
>>>

-- 
Dmitry Konstantinov

Reply via email to