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