On Fri, Jan 15, 2016 at 7:48 PM, John Burwell <john.burw...@shapeblue.com> wrote:
> Motivation > ======== > > The current monthly release cycle addresses the needs of users focused on > deploying new functionality as quickly as possible. It does not address the > needs of users oriented towards stability rather than new functionality. > These users typically employ QA processes to comply with corporate policy > and/or regulatory requirements. To maintain a growing, thriving community, > we must address the needs of both user types. Therefore, I propose that we > overlay a LTS release cycle onto the monthly release cycle to address the > needs of stability-oriented users with minimal to no impact on the monthly > release cycle. This proposed LTS release cycle has the following goals: > > * Prefer Stability to New Functionality: Deliver releases that only > address defects and CVEs. This narrowly focused change scope greatly > reduces the upgrade risk/operational impact and shorter internal QA cycles. > * Reliable Release Lifetimes: Embracing a time-based release strategy, the > LTS release cycle will provide users with a reliable support time frames. > Users can use these time frames provide users with an 20 month window in > which to plan upgrades. > * Support Sustainability: With a defined end of support for LTS releases > and a maximum of two (2) LTS releases under active maintenance at any given > time, community members can better plan their commitments to release > support activities. We also have a agreed upon policy for release > end-of-life (EOL) to debate about continuing work on old releases. > > Proposed Process > ============== > > LTS release branches will be cut twice year on 1 Jan and 1 July from the > tag of the most recent monthly release. The branch will be named <base > version>-LTS and each LTS release will be versioned in the form of <base > version>-<LTS revision number>. For example, if we cut an LTS branch based > on 4.7.0, the branch would be named 4.7.0-LTS and the version of the first > LTS release would be 4.7.0-0, the second would be 4.7.0-1, etc. This > release naming convention differentiates LTS and monthly releases, > communicates the version on which the LTS release is based, and allows the > maintenance releases for monthly releases without version number > contention/conflict. Finally, like master, an LTS branch would be always > deployable following its initial release. While it is unlikely that LTS > users would deploy from the branch, the quality discipline of this > requirement will benefit the long term stability of LTS releases. All PRs > targeting an LTS would require two LGTMs in order to be merged. > > The following are the types of changes that would permitted and guarantees > provided to users: > > * No features or enhancements would be backported to LTS release branches. > * Database changes would be limited to those required to address the > backported defect fixes. > * Support for the release/version of the following components from the > release on which the LTS is based throughout the entire release cycle: > * MySQL/MariaDB > * JDK/JRE > * Linux distributions > * API compatibility for between all LTS revisions. API changes would be > limited to those required to fix defects or address security issues. > > An LTS release would have a twenty (20) month lifetime from the date the > release branch is cut. This support period allows up to two (2) months of > branch stabilization before initial release with a minimum of eighteen (18) > months of availability for deployment. LTS releases would have the > following support periods: > > * 0-14 months: backport all defect fixes in the scope of the LTS release > functionality; fix all blocker and critical priority defects identified in > the branch > * 14-20 months: backport only CVE fixes in the scope of the LTS release > functionality; fix all blocker priority defects in the branch > > Defect fixes that originate in an LTS branch will be pulled forward to > master only. Finally, an LTS branch should be release the fewest times > necessary to deliver fixes in a relatively timely manner. Therefore, LTS > releases will be triggered based on the number of pending of fixes and > their severity with no defect fix awaiting release more than forty-five > (45) days. CVE fixes would trigger an immediate release of an LTS branch. > > Is this going to be official ASF CloudStack releases following the necessary protocol of vote periods, binding votes etc. or will this be a community release by 3rd parties? I am asking now so that we are all on the same page here when we get to the first release. > Resourcing and Proposed Timeline > =========================== > > Broad community support is vital to guarantee the twenty (20) month > support period for each LTS branch. Given the ebbs and flows of > contribution and committer priorities, ShapeBlue will provide a release > manager, as well as, engineering support to fill any contribution gaps to > ensure that the community fulfills LTS commitments. > > In order to prepare for supporting LTS releases, we would need to complete > the following items: > > 1. All tools that do version number comparisons would be made aware of the > LTS versioning scheme > 2. Officially support running the management server on Java 8 since Java 7 > has been EOL since last April [1] (i.e. compile to 1.7 with the Java 1.8 > compiler and run on Java 1.8). Providing a 20-month support window on an > EOL JVM is an unacceptable security risk. > 3. Update the wiki and website to explain the new release cycle and help > users decide which release type suits their needs > 4. Define an initial test plan for LTS stabilization > 5. Agree on the definitions of ticket severities > > In order to address these items and start on a regular rhythm, I propose > that first LTS cycle begin on 1 July 2015. In the interim, we would > continue to ship critical bug fixes from the 4.5 release as this release > seems to be the most commonly deployed in the community. > 1 July 2016 I assume? :-) > > Together, the monthly and LTS release cycles address the needs of the > entire Apache CloudStack user community. I believe that the process > described in the proposal will yield releases that meet the needs of users > requiring release stability without adversely affecting the velocity of the > monthly release cycle. > > Huge +1. I understand that a lot of people want fast and rapid releases, but that does not work for everyone, me included. I'll most likely run LTS in production, but latest monthly in labs/testing. -- Erik
