> 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? The text we're voting on right now leaves us flexible on: 1. What we decide to "API Break" 2. How we decide to "API Break" We reached a consensus on that previous discussion of "hit dev ML with [DISCUSS] for any API introduction or removal", so I *think* we're good with the text here as written and don't need to revise and re-call the vote.
While strictly the text as written confines us to a deprecate in N then remove in N+1 MAJOR, the combination of this with our consensus on our default posture as "never break API if we can help it" means that the only situations in which we actually need to break an API would be extreme circumstances (unworkable lossy API, security risk, etc) where deprecating then removing in next MAJOR would make sense. To distill: • Try never to break API • In the rare case we *have* to break an API, we need to: • Have a dev ml [DISCUSS] thread about it w/consensus • Have it for at least 1 MAJOR in deprecated status (deprecate-then-remove) • Then remove in N+1 That'd probably end up being at a minimum 12 months since that's our time between majors. How does that sit with you Joey? On Wed, Apr 23, 2025, at 11:49 AM, Bernardo Botella wrote: > +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> 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
