> So here's what I'm thinking: a new release strategy that doesn't use .MINOR > of semver. Goals:
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)? My first instinct is to not like this, but its not been easy to keep up with the JDK releases… every time we add a new JVM we need to make breaking changes... > On Apr 10, 2025, at 1:54 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?
