> 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?
