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?