cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Weber <terbol...@gmail.com>
Subject Re: [PROPOSAL] LTS Release Cycle
Date Fri, 15 Jan 2016 21:26:47 GMT
On Fri, Jan 15, 2016 at 7:48 PM, John Burwell <john.burwell@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message