On Thu, Nov 1, 2012 at 11:07 PM, Chip Childers <chip.child...@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
