Fwd: [PROPOSAL] LTS Release Cycle

[Ron Wheeler]

There has been a long discussion about release strategies in the Apache
Cloudstack forum.
This is an interesting proposal that has been fleshed out to a pretty
good level of detail.

Although Cloudstack and OFBiz serve very different areas, both could be
described as critical applications where downtime and instability will
have very high corporate visibility.
Security is important to both and fixes to underlying third party
software can come at any time and they may force upgrades to the
application unexpectedly.
Bugs need to be fixed as well.

They are currently issuing an  official release every month which gets
new features and bug fixes out quickly but is causing some discomfort
for the majority of the system administrators who can not keep up with
that pace given the amount of internal certification required and the
inability to stand that frequency of maintenance downtime.

This tries to balance the thirst for new features with the need for
stability and attempts to move the decision about upgrades to the user
by reducing the pain of not upgrading so often while providing a way for
those who need the bleeding edge to have access to bug fixes and new
features quickly.

Ron

-------- Forwarded Message --------

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: *[phone] | s: [phone] *
<tel:+44%20%2820%29%203603%200542%20%7C%20s:%20+1%20%28571%29%20403-2411>

e: *[hidden email] | t: *
<mailto:[hidden email]%20%7C%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/>