cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <john.burw...@shapeblue.com>
Subject [PROPOSAL] LTS Release Cycle
Date Fri, 15 Jan 2016 18:48:36 GMT
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


[cid:imagef869f6.png@4b2b18aa.44bcb591]


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/>

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