We will hold this against you only shortly, John. Thanks for writing out the planning.
On Tue, May 31, 2016 at 12:33 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 > > > > > > -- Daan
