Daan and Erik, @Erik Reading through the proposal, I realize that I was not explicit. LTS releases would be official ASF releases following the same voting procedures as any other release. Also, realized that I have a bit a math fail in my proposal. The cut dates are intended to be six (6) months apart. Therefore, the cut dates should be 1 January and 1 June. Therefore, I propose that we cut the first LTS branch from the most recent monthly release as of 1 June 2016.
@Daan As many people reflected in the previous discussion about release cadence, many users are wedged between enduring workarounds for significant defects and a level of upgrade risk that is not acceptable to them. For these users, releases are in use for 12-18 months which means that they are often forced to accept some significant workarounds to keep their systems stable (e.g. 4.5.2 VMWare users can’t use DRS with advanced networking due to VR being rebooted on DRS migrations). Keeping all of the previous monthly releases updated with important bug fixes is not tenable. LTS allows us to maintain a release branch to support users who must run a release for a 12-18 months without having to compromise their operational capability to preserve system stability. In terms of the merge strategy, nothing about the current process would change. Defects would be fixed on the branch where they occurred and then forward ported to master. For each maintained LTS branch less than 14 months old, only blocker and critical defects that fall within the LTS’ branch scope would be pulled back from master. Therefore, the number of defects backported should be relatively small. Any defects found and fixed in an LTS branch would be forward ported to master. I will clarify the proposal to establish this merge pattern to ensure that LTS does not violate or impede the flow of defect fixes on master and maintained monthly releases. Thanks, -John > [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.burw...@shapeblue.com | t: <mailto:john.burw...@shapeblue.com%20|%20t:> | w: www.shapeblue.com<http://www.shapeblue.com> a: 53 Chandos Place, Covent Garden London WC2N 4HS UK [cid:imageff218b.png@a664b8fc.4fa0ac20] 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. On Jan 16, 2016, at 5:07 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > > +0, John, I admire your efforts but I would like to see a proposal more in > line with our present process for PR merging and releasing. For 4.5 we have > a bootstrap problem, here so that would reauire a transistion period > (unless we start branding our LTS on 4.7) I also don see the neccesity for > anything beyond tiny version. I think it is confusing. So I would prefer > going for 4.7.1 ...2 ...3 etc or 4.5.4 ...5 ...6 if you wish. And next I am > not attracted to the back-porting bit. We should make sure bugs are fixed > on the commit that caused them and then forward ported to any branch that > needs them, including master and LTS. > > That all said, I see a feasible plan so please go ahead. > > On Fri, Jan 15, 2016 at 10:26 PM, Erik Weber <terbol...@gmail.com> wrote: > >> On Fri, Jan 15, 2016 at 7:48 PM, John Burwell <john.burw...@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 >> > > > > -- > Daan 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/>
