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