cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [DISCUSS] Release Cycle
Date Tue, 31 May 2016 10:50:14 GMT
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.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
> >
> >
>
>


-- 
Daan

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message