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?