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
