cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abhinandan Prateek <abhinandan.prat...@shapeblue.com>
Subject Re: [DISCUSS] Release Cycle
Date Wed, 01 Jun 2016 05:40:57 GMT
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" <john.burwell@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 <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
>> 
>> 
>

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


Mime
View raw message