Just realized that the other thread is for [vote]. Posting my question here instead...
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? On Wed, Apr 16, 2025 at 5:15 AM Josh McKenzie <jmcken...@apache.org> wrote: > 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 > > Does the clarification in the earlier thread help shift your perspective / > address your concerns here David? > > Will leave this thread for another 24 hours to see if there's any other > concerns and call a vote if not. > > Thanks everyone for the engagement. > > On Fri, Apr 11, 2025, at 11:22 AM, Josh McKenzie wrote: > > So we avoid 6.1, 7.2, etc? Does this imply that each release is allowed > to make breaking changes (assuming they followed the “correct” deprecation > process)? > > Yes and no. > > A release can't make a breaking change *relative to the immediately > preceding release*, if something has been deprecated. > > A release *can* make a breaking change *from another actively supported > release* if it's not an adjacent release and the feature was signaled as > deprecated in the interim release. > > On Fri, Apr 11, 2025, at 10:39 AM, Jon Haddad wrote: > > +1. > > It's the proper signal to the community. A .1 release could still be done > as an exception, but I have a hard time thinking of a case other than > supporting a newer JDK without any other changes. > > On Fri, Apr 11, 2025 at 7:19 AM Jeremiah Jordan <jerem...@apache.org> > wrote: > > +1 from me. > No more wondering what the next version number will be. > No more wondering what version I can upgrade from to use the new release. > > -Jeremiah > > On Apr 10, 2025 at 3:54:13 PM, Josh McKenzie <jmcken...@apache.org> wrote: > > > This came up in the thread from Jon on "5.1 should be 6.0". > > I think it's important that our release versioning is clear and simple. > The current status quo of: > - Any .MINOR to next MAJOR is supported > - Any .MAJOR to next MAJOR is supported > - We reserve .MAJOR for API breaking changes > - except for when we get excited about a feature and want to .MAJOR to > signal that > - or we change JDK's and need to signal that > - or any of another slew of caveats that require digging into NEWS.txt > to see what the hell we're up to. :D > - And all of our CI pain that ensues from the above > > In my opinion the above is overly complex and could use simplification. I > also believe us re-litigating this on every release is a waste of time and > energy that could better be spent elsewhere on the project or in life. It's > also a signal about how confusing our release versioning has been for the > community. > > Let's leave aside the decision about whether we scope releases based on > time or based on features; let's keep this to the discussion about how we > version our releases. > > So here's what I'm thinking: a new release strategy that doesn't use > .MINOR of semver. Goals: > - Simplify versioning for end users > - Provide clearer contracts for users as to what they can expect in > releases > - Simplify support for us (CI, merges, etc) > - Clarify our public API deprecation process > > Structure / heuristic: > - Online upgrades are supported for all GA supported releases at time of > new .MAJOR > - T-1 releases are guaranteed API compatible > - We use a deprecate-then-remove strategy for API breaking changes > > This would translate into the following for our upcoming releases > (assuming we stick with 3 supported majors at any given time): > 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 > > So: what do we think? > > > >
