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