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.prat...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue On 31/05/16, 4:03 PM, "John Burwell" <john.burw...@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.burw...@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.burw...@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.burw...@shapeblue.com >> www.shapeblue.com >> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK >> @shapeblue >> >> > abhinandan.prat...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
