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.burw...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue
