On Wednesday, July 13, 2011 08:16:09 AM Beman Dawes wrote:
Give we are already in the middle of July, I feel strongly 1.48.0 should target the first Monday in November, thus putting us back on our usual quarterly cycle. In our earlier schedule discussion, there was some interest in a three times a year release schedule, but the arguments were not convincing to me, so I really think we should keep to our quarterly schedule.
The current formula for intermediate dates goes like this:
* One week after prior release ships: branches/release opens for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager. * Seven weeks before release: branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries. * Six weeks before release: QA checks on snapshot doc builds, inspect status, getting started guide, and install. * Four weeks before release: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. * Three weeks before release: branches/release closed for all library changes except when specific permission given by release manager(s). * Two weeks before release: Beta target date. Further betas and/or release candidates as feedback dictates.
I propose that the Beta be scheduled for *Four* weeks before the release target date. All the other intermediate dates would thus be two weeks earlier.
That's more or less what we did for 1.47.0 and it allowed enough time to fix a bunch of bugs in the beta that were bothering users.
Sounds very good to me! What are the chances of having a 1.47.1 point release?
--Beman