cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <john.burw...@shapeblue.com>
Subject Re: [PROPOSAL] LTS Release Cycle
Date Tue, 19 Jan 2016 02:54:27 GMT
Ilya,

Unless we have a bug fix that addresses a significant, widespread system stability problem
or a high priority/impact security issue, an LTS will roll up a number of fixes.   Each release
would receive the full system test to verify that the patch set does not introduce regression
defects.  I believe that most LTS users want a few releases as necessary to keep their systems
up-to-date and stable because each upgrade carries operational risk and downtime.  Therefore,
the process should strive to make as a few releases as necessary to achieve this goal.

Thanks,
-John

> On Jan 15, 2016, at 3:22 PM, ilya <ilya.mailing.lists@gmail.com> wrote:
>
> John
>
> Thank you for taking time writing out the LTS proposal.
>
>> 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.
>
> You guys rock!!
>
> I'm +1 on this,
>
> Can you please expand on the QA side of LTS. Since this is more around
> long term bug/security fix - i'd think - the testing will be minimal, to
> the scope that fix applies - which will speed up the release process in
> general. What are your thoughts on this?
>
>
> Thanks
> ilya
>
>
>
>
>
> On 1/15/16 10:48 AM, John Burwell 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.
>>
>> 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.
>>
>> 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.
>>
>> Thanks,
>> -John
>>
>> [1]: http://www.oracle.com/technetwork/java/eol-135779.html
>>
>>
>> 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
>>
>> 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.
>>
>>
>> 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/>

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/>
Mime
View raw message