John, Something is not clear to me about the frequency of new LTS releases and support time range.
You wrote in the proposal, that we branch off for a new LTS version 2 times a year, but only 2 LTS versions will in active maintained at any time, but supported for 20 months. This conflicting in my mind. This means we do not branch off _every_ year twice? Otherwise we would have 3 releases within 12 months 1.1/1.7/1.1. And the support will be only ~13 months for max as we do not maintain 3 releases. What I am missing? René On Tue, 02 Feb 2016 16:40:42 GMT, John wrote: > All, > > Based on the feedback from Ilya, Erik, and Daan, I have updated my > original LTS proposal to clarify that LTS releases are official project > deliverables, commit traceability across branches, and RM approval of PRs: > > ## START ## > > 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. > > LTS releases would be official project releases. Therefore, they would > be subject to same release voting requirements and available from the > project downloads page. > > Proposed Process > ================ > > LTS release branches will be cut twice year on 1 Jan and 1 July based > 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. Like master, all PRs targeting an LTS branch would > require two LGTMs (one code review and one independent test), as well > as, an LGTM from the branch RM. A combined code review/test LGTM and an > RM LGTM would be acceptable. > > 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. The twenty (20) > month LTS lifecycle would be divided into following support periods: > > * 0-2 months (average): Stablization of the LTS branch with fixes > based on defects discovered from functional, regression, endurance, and > scalability testing. > * 2-14 months: backport blocker and critical priority defect fixes in > the scope of the LTS branch functionality; fix all blocker and critical > priority defects identified on the LTS branch > * 14-20 months: backport only CVE fixes in the scope of the LTS branch > functionality; fix all blocker priority defects identified on the LTS branch > > Defect fixes that originate in an LTS branch would 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 the immediate release of > an LTS branch. > > Users and developers must be able to verify that all fixes applied to an > LTS are carried forward to future releases. Therefore, any commits > backported to an LTS branch from master must merged in a traceable > manner. To demonstrate the feasiblity of using git merge for this > purpose, I have put together a gist [1] to create traceability by > backporting a change from a master to a maint branch. > > 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 2016. In the interim, we would > continue to ship critical bug fixes from the 4.5 branch as it seems to > be a defacto LTS branch by our users. > > 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. > > [1]: https://gist.github.com/b06a68193c8f46f41e14 > [2]: http://www.oracle.com/technetwork/java/eol-135779.html > > ## END ## > > If no significant issues are raised by COB Friday, 5 Feb 2016, I will > open a vote on this proposal Monday, 8 Feb 2015 with the hope of gain > agreement on an LTS release cycle by the end of next week (12 Feb 2016). > > Thank you again for the great feedback — I think it has greatly improved > the proposal, > -John >
