On 13 July 2011 13:16, Beman Dawes <bdawes@acm.org> wrote:
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.
I think it'd be a good idea to ask on the list what's planned for the next release, mainly for new libraries but also incoming changes to existing libraries.
* 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.
If this is brought forward by 2 weeks, it will become 9 weeks before release, which seems a bit tight. A release cycle lasts from 12 to 14 weeks. We open the release branch after 1 week, so that leaves 2 to 4 weeks, which can be significantly reduced if the previous release was late, or there's a point release. Keeping it at 7 weeks, or maybe 8, would be better IMO.
* Six weeks before release: QA checks on snapshot doc builds, inspect status, getting started guide, and install.
Does anyone actually observe this one? I tend to check the documentation for new libraries as they're added, and then the whole of the documentation much later.