I would like to get a better understanding of "but only for features that have already been deprecated for one major release cycle."
Does it mean that one has to flag a feature as deprecated in the unreleased version N, wait until when N is released (deprecating for one major cycle), and then finally make the breaking change in N + 1? Similarly, for a released version, say M (where trunk is at N), should the author patch M to mark the feature as deprecated, and wait until N is released (deprecating for one major release cycle), and introduce the breaking in N + 1? It would be nice to have examples to clarify the deprecation/breaking change policy. The examples on version bumping are helpful. - Yifan On Thu, Apr 17, 2025 at 10:16 AM Brandon Williams <dri...@gmail.com> wrote: > +1 > > Kind Regards, > Brandon > > On Thu, Apr 17, 2025 at 10:59 AM 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. >
