Re: [DISCUSS] How we version our releases

[Benedict]

I proposed dropping Minor versions a few years ago so I’m cool with this, but regarding policies I do think we’d be better off just creating a version compatibility matrix and quit agonising over it. With N policies across N releases I’m not sure they’re providing much certainty to users.  We really just need a consistent mechanism for deciding upgrades. A compatibility matrix solves that problem, and we can safely update this across all of our present, past and future inanities. On 11 Apr 2025, at 08:15, Mick Semb Wever <m...@apache.org> wrote:  On Thu, 10 Apr 2025 at 22:54, Josh McKenzie <jmcken...@apache.org> wrote: … 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 … So: what do we think? +1  David, yeah, we avoid .1 minor releases altogether. IIUC this does not imply allowing breaking changes.  That ties into the recent thread about aiming to maintain compatibility forever.  That after a deprecation cycle, wanting to remove/break anything requires a discussion and evaluation to the cost of keeping that legacy/deprecated code. WRT jdks, Everytime we drop a jdk, we drop testing all upgrade paths from versions where that was the highest jdk.  In 6.0 if we drop jdk11 then we will stop testing upgrades from 4.x versions.  Our tests don't support it, but we also need to at some point for the sake of keeping the test matrix sane to our CI resources. The previous versioning scheme meant we chose when to drop a jdk (or break the upgrade supported paths).  The proposed versioning scheme means we have to wait and align dropping jdks with the T-2 approach.  I think it's a great idea that we internalise this cognitive load, making it simpler for the user.