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.
