incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [ASFCS41] Proposed schedule for our next release
Date Mon, 12 Nov 2012 21:28:20 GMT
On Thu, Nov 1, 2012 at 11:07 PM, Chip Childers
<chip.childers@sungard.com> wrote:
> Following up on the previous thread about this topic, I'd like to
> propose the following release calendar for our next feature release.
>
> First, note the subject tag of "[ASFCS41]".  I'm making 2 assumptions
> right now.  First, that we should adopt semantic versioning for our
> versioning scheme.  Second, that our next feature release will be
> backward compatible with 4.0.0-incubating.  Note that I'm NOT
> discussing bug fix releases below.  Shout if you disagree with either
> assumption!
>
> Before the schedule, here's what I'm looking for people to think about
> when reading this:
>
> * Developers, does a 2 month window to get new stuff into a master for
> the feature release work?  Do you think that this is enough time to
> deal with the bugs that come out of testing?
>
> * Docs contributors, does this give us enough time (assuming
> concurrent development of docs for new features as much as possible)?
>
> * Translators, can we get translation updates completed in this
> window?  Also, should we be planning on getting more of our content
> translated as part of the "feature development" of the next release
> (hoping that we limited the end of release cycle translations to only
> new strings / docs)?
>
> * QA folks, does this schedule provide enough time for feature
> testing?  I know that's always an unknown, since we don't actually
> know WHAT features will make it in by the cut-off date.  But is it a
> reasonable schedule based on past performance?
>
> Here's the proposed schedule:
>
> 2012-11-01 through 2012-12-30
>   Feature and documentation development (obviously ongoing, but
> continued during this period)
>
> 2012-12-31
>   Feature Freeze
>   All new feature need to have been merged into master by this date.
>   Release branch will be cut on this date.
>   Jenkins updated to include new release branch builds.
>
> 2013-01-01 through 2013-01-30
>   Doc Updates
>   Testing/Bug Fixes (testing against jenkins artifacts)
>
> 2013-01-31
>   Docs Freeze (except release notes and translations)
>   Release Branch moves to limited updates only (only commits allowed
> in would be release blockers fixes, translation updates, etc...)
>
> 2013-02-01 through 2013-02-22
>   Translation Development and Integration (should be ongoing, but
> focused effort)
>   Final regression testing / bug fixes / doc fixes
>
> 2013-02-16 through 2013-02-24
>   Final regression testing / bug fixes / doc fixes
>
> 2013-02-25
>   4.1.0-RC1 is created, and project level VOTE is called
>
> We'll have to remember that a couple of rounds might be needed for the
> vote (just like this time), but if we start on Feb 25, the "happy
> path" gets us to a potential release announcement date of 2013-03-05.
> This is based on 72 hours at of voting at the project level,
> immediately closing the vote and opening the IPMC vote for another 72
> hours, closing that and doing the actual release over the weekend.
> Lots of assumptions in that last bit of the timeline (hence, I don't
> think it's possible to realistically schedule the voting process with
> certainty).
>
> In reality, we will probably end up doing at least 2 voting rounds at
> the project level.  However, IMO, the issues that come up during the
> voting process should be limited to a smaller number of high priority
> bugs that might have cropped up out of the blue, as well as any
> formalities that were incorrectly dealt with during the rest of the
> cycle (e.g.: a new dependency that we didn't document).  If we end up
> running multiple release votes, most of the community will be able to
> move on to the next release activities during that period of time (of
> course, testing the RC's and voting is always critical).  The impact
> will always be that the actual date of the release is predicated on
> the voting process and it's associated timings.
>
> Thoughts?
>
>
> -chip

Taking everyone's input into consideration, I've reworked the proposed
schedule (below).  I've extended the feature dev period until the end
of Jan, giving us a 5 month (3 for features, 2 for testing / wrap-up)
schedule for this next release.

Does this sound like something we can all get behind?  Did I miss any
significant issues raised in this or other threads?

If the 4.1 schedule proposal works, I'd further propose that we shift
to a 4 month schedule for feature releases afterward. IMO, we should
be basically developing features outside of a release, and bringing
them into master when the window is open for inclusion in the next
release.  This gives any developer as much time as they would like
(although the longer it goes on, the harder it is to potentially
integrate back into master), and the community gets a clear view of
what our "time-based" release schedule will look like.

This rhythm would set us up with the following high level dates:

================================
Proposed schedule for ongoing releases
================================
4.1
  Nov through Jan - Feature work
  Feb and March - Testing / Hardening / Wrap-up
4.2
  April and May - Feature work
  June and July - Testing / Hardening / Wrap-up
4.3
  August and September - Feature work
  October and November - Testing / Hardening / Wrap-up
4.4
  Start all over in Dec

** This assumes no major version increments, but we could certainly have one!

=============================
New 4.1 detailed schedule proposal:
=============================

2012-11-01 through 2013-01-31
  Feature and documentation development (obviously ongoing, but
continued during this period)

2013-01-31
  Feature Freeze
  All new feature need to have been merged into master by this date.
  Release branch will be cut on this date.
  Jenkins updated to include new release branch builds.

2013-02-01 through 2013-02-28
  Testing/Bug Fixes (testing against jenkins artifacts)
  Documentation Finalization

2013-02-28
  Docs Freeze (except release notes and translations)
  Release Branch moves to limited updates only (only commits allowed
in would be release blockers fixes, translation updates, etc...)

2013-03-01 through 2013-03-22
  Translation Development and Integration (should be ongoing, but
focused effort)
  Final regression testing / bug fixes / doc fixes

2013-03-22
  4.1.0-RC1 is created, and project level VOTE is called

Mime
View raw message