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> wrote: > +1 > > On Tue, Apr 22, 2025 at 8:52 AM Dmitry Konstantinov <netud...@gmail.com> > wrote: > >> +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 >> >
