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 > >
