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

Reply via email to