Re: [DISCUSS] Release Cycle

[Abhinandan Prateek <ab...@shapeblue.com>]

Hi John,

Thanks for detailed email on release cadence.
A 2 month release cycle with an LTS release every 6 month is the middle ground.
With CI evolving in terms of participation, coverage quality and test case quality we will be looking forward to still better cloudstack releases.

Regards,
-abhi

abhinandan.prateek@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue








On 31/05/16, 4:03 PM, "John Burwell" <jo...@shapeblue.com> wrote:

>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 <jo...@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
>> 
>> 
>

abhinandan.prateek@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue