cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <john.burw...@shapeblue.com>
Subject Re: [DISCUSS] Release Cycle
Date Tue, 31 May 2016 10:33:03 GMT
All,

Quick correction below: I misquoted the LTS proposal — branches are cut on 1 January and
1 _July_ (not June).

I apologize for the mistake,
-John

> 
john.burwell@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On May 31, 2016, at 12:28 AM, John Burwell <john.burwell@shapeblue.com> wrote:
> 
> All,
> 
> Over the course of the last 6-8 months, we have attempted to release monthly.  We successfully
delivered 4.6, 4,7, and 4,8 using this model.  We also established a strong set of CM and
review principles to improve the quality of releases [1].  To support users that are unable
to upgrade on a monthly basis, we have proposed adding an LTS release cycle that will provide
an 18 month support window for releases that are cut twice a year (January and June).  We
are on track for two types of releases — regular and LTS releases.
> 
> Reflecting on the monthly release cycle, we spent at least 8 days a month preparing and
voting out releases.  This cadence left an average of 12 days a month to build features. 
In my experience, this cadence impeded efforts to build larger features or address large architectural
issues.  Therefore, for regular releases, I propose we elongate the release cycle from one
(1) month to two (2) months with the following phases:
> 
>    * Development: 6 weeks (42 days)
>    * Release Preparation/Test: 1 week (7 days)
>    * RC Voting: 1 week (7 days)
> 
> In order to ensure the timeliness of releases and avoid indecision, these timeframes
would be hard limits.  Therefore, the development phase would close at 6 weeks — no exceptions.
 Finally, we would only support the current and previous regular release.  For example, we
would only provide support for 4.8 and 4.9 releases until 4.10 is released when 4.8 would
reach end of life.  This cycle would continue to use the same release principles(e.g. master
frozen during release preparation/test and RC voting, 2 LGTM per PR, etc).  I believe this
longer cycle would provide a regular, responsive release cycle and enough development time
to build larger features.
> 
> Per the LTS proposal [2], LTS branches would be cut from the most recent stable release
branch as of 1 January and 1 June every year.  Upon creation, each LTS branch would go through
a 6 week stabilization/test process.  Following their initial release, these branches releases
receive applicable blocker, critical, and CVE fixes for 12 months.  Ideally, defect fixes
that apply to both LTS and regular releases will be applied to oldest LTS release and forward
merged.  Additional LTS maintenance releases will occur based on an as-needed basis — balancing
release frequency and stability.
> 
> Based on these two release cycles, regular and LTS, the release calendar for the next
twelve (12) months would be as follows:
> 
>    * LTS 4.9.0_1 (Release Date: 21 August 2016/EOL: 21 April 2018)
>        * Stabilization/Testing: 1 July - 14 August 2016
>        * RC Voting: 14-21 August 2016
>    * 4.10.0 (Release Date: 28 August 2016/EOL: 18 December 2016)
> * Development: 1 July - 14 August 2016
> * Testing: 14-21 August 2016
>        * RC Voting: 21-28 August 2016
>    * 4.11.0 (Release Date: 23 October 2016/EOL: 12 February 2017)
>        * Development: 28 August - 9 October 2016
>        * Testing: 9-16 October 2016
>        * RC Voting: 16-23 October 2016
>    * 4.12.0 (Release Date: 18 December 2016/EOL: 2 April 2017)
>        * Development: 23 October - 4 December 2016
>        * Testing: 4-11 December 2016
>        * RC Voting: 11-18 December 2016
>    * 4.13.0 (Release Date: 12 February 2017/EOL: 4 June 2017)
>        * Development: 18 December 2016 - 29 January 2017
>        * Testing: 29 January - 5 February 2017
> * RC Voting: 5-12 February 2017
>    * LTS 4.12.0_1 (Release Date: 19 February 2017/EOL: 19 October 2018)
>        * Stabilization: 1 January - 12 February 2017
>        * RC Voting: 19 February 2017
>    * 4.14.0 (Release Date: 2 April 2017/EOL: 30 July 2017)
> * Development: 12 February - 26 March 2017
>        * Testing: 26 March - 2 April 2017
>        * RC Voting: 2-9 April 2017
>    * 4.15.0 (Release Date: 24 April 2017/ EOL: TBD)
> * Development: 26 March - 22 May 2017
> * Testing: 22-29 May 2017
>        * RC Voting: 29 May - 4 June 2017
>    * 4.16.0 (Release Date: 30 July 2017/ EOL: TBD)
> * Development: 4 June - 16 July 2016
> * Testing: 16-23 July 2016
> * RC Voting: 23-30 July 2016
>    * LTS 4.15.0_1 (Release Date: 27 August 2017/ EOL: 27 April 2019)
> * Development: 1 July - 13 August 2017
> * Testing: 13-20 August 2017
> * RC Voting: 20-27 August 2017
> 
> A few notes/questions regarding this schedule:
> 
>    1. The 4.10 cycle officially starts on 1 July to synchronize with the beginning of
an LTS cycle and to ensure that there is ample time for 4.9 to be voted out.  Assuming 4.9
releases before 1 July, the 4.10 development phase would still end on 14 August 2016 to maintain
a regular cadence.  Therefore, the 4.10 development phase will likely be a 1-2 weeks longer
than other releases.
>    2. The calendar lined up neatly to have each phase end on a Sunday.  This alignment
affords developers a weekend to complete any outstanding.  However, the downside is that votes
may close on Sundays.  An alternative would be to round up/down to end phases on Fridays.
 Personally, I have no strong feelings either way.
>    3. Per the proposal, all minor LTS releases are performed on an as-needed basis. 
Therefore, it is not possible to plan them in advance.
>    4. We should schedule regular minor releases for each regular release.  Would delivering
a minor release for each supported regular release make sense?
>    5. Release numbers assume that we will not release 5.0.0 in the next 12 months.  If
we were to release 5.0.0, I propose adjust the versions without changing the dates.
> 
> Once we gain agreement on a release schedule, we will be able to update the community
roadmap [3] based on the release calendar.  Together, this information will allow users to
plan infrastructure upgrades up to 12 months in advance.
> 
> Thanks,
> -John
> 
> [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up
> [2]: http://markmail.org/thread/zh43rc6ahs4te46l
> [3]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Roadmap
> 
> john.burwell@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
> 
> 

Mime
View raw message