cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rene Moser <m...@renemoser.net>
Subject Re: [PROPOSAL] LTS Release Cycle
Date Mon, 08 Feb 2016 10:46:23 GMT
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
> 

Mime
View raw message