Re: [PROPOSAL] LTS Release Cycle

[John Burwell <jo...@shapeblue.com>]

Rene,

I apologize for lag in my reply — I have been a bit consumed by the $dayjob lately.

At any given time, the two most recent LTS releases receive full support (back port of blocker/critical fixes + CVE patches). The oldest LTS release only receives CVE patches. Given the infrequency of CVE patches, there would very little effort required for the oldest LTS release. I will update the proposal to change the active number from 2 to 3. However, in terms of effort, the 2 most recent releases will represent the nearly all of the LTS effort. The primary motivation for having the third overlapping LTS release is to provide users that require longer update cycles (e.g. 18 months) a bridge to upgrade.

Thanks,
-John

>

[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue

d:      +44 (20) 3603 0542 | s: +1 (571) 403-2411 <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>

e:      john.burwell@shapeblue.com | t: <mailto:john.burwell@shapeblue.com%20|%20t:>     |      w:      www.shapeblue.com<http://www.shapeblue.com>

a:      53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:imagece4572.png@b6bb1072.42b186b6]


Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.




On Feb 8, 2016, at 5:46 AM, Rene Moser <ma...@renemoser.net> wrote:
>
> 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
>>

Find out more about ShapeBlue and our range of CloudStack related services:
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>