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 [ASFCS41] Proposed schedule for our next release
Date Fri, 02 Nov 2012 03:07:12 GMT
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

Mime
View raw message