Shipping patch releases
To be Reviewed By:
Authors: Anthony Baker
Status: Draft | Discussion | Active | Dropped | Superseded
Superseded by: N/A
Related: N/A
Problem
The Geode project has been following a model of shipping releases quarterly [1][2]. Using the SemVer [3] approach, these quarterly releases are labeled as minor versions. Occasionally, the project has shipped patch releases [4] to address security vulnerabilities or really critical bugs. However, on the whole the project has asked users to wait until the next quarterly minor release to receive improvements and fixes.
It would benefit our user community if we supported our releases for a period of time by back porting important fixes and providing patch releases.
Solution
What stays the same: we continue shipping minor releases on a quarterly schedule.
What is different: in addition to quarterly minor releases, we will provide patch releases for N, N-1, N-2 versions starting with the upcoming 1.12.0 release. These patch releases would be ad-hoc (as needed) and ideally limited to no more than one per month across each minor version.
What this looks like:
Release 1.11.0 will be superseded by 1.12.0 and receive no patches except as needed under the prior policy.
When 1.12.0 is released (3/2020), it will be supported by the community until 1.15.0 is released (12/2020).
When 1.13.0 is released (6/2020), it will be supported by the community until 1.16.0 is released (3/2021).
When 1.14.0 is released (9/2020), it will be supported by the community until 1.17.0 is released (6/2021).
When 1.15.0 is released (12/2020), it will be supported by the community until 1.18.0 is released (9/2021).
And so on*.
* note that these dates and releases for for example purposes only. Our plans may change!
When a new major version of Geode is released (e.g. 2.0) we will follow the same pattern. We may decide to extend support for the final minor version of the prior major to allow our users sufficient time to upgrade.
FAQ
How will we handle the increased volume of releases?
We will need to review our release practices and determine where we can optimize and streamline. This should include considerations such as assigning semi-permanent community release managers to support branches, automation of release tasks, PMC review and voting, etc.
What changes should be back ported to a support branch?
The community will exercise good judgement in the same way that important changes are cherry-picked onto release branches prior to shipping a new release. Fixes related to data safety and consistency, cluster stability, or API behaviors are good candidates to be considered.
What changes should NOT be back ported to a support branch?
New features, refactoring changes, or less important and non-critical bug fixes. Of course, you are always free to advocate within the community and state your case!
Will EVERY change be back ported to EVERY support branch?
No, only issues deemed critical and / or important will be back ported. Even then, some changes may be too difficult or risky to back port because of the scope of changes needed. As a general rule, users expect that if a fix is present in release N-2 it should also be present in N-1 and N releases.
Why not do LTS (long-term support) releases?
The best version of Geode is the most recent version and our users benefit from upgrading and receiving new fixes and improvements.
When I fix a bug what branch(es) will I back port it onto?
Assuming this is a critical bug, you would make the fix on the /develop branch and back port it onto N, N-1, and N-2 release branches. Following the release of a new minor version, we will create a /support/x.y branch to use for releasing patch versions.
References
[1] https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule
[3] https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching