Le 08/04/13 12:36, Daniel James a écrit :

On 8 April 2013 07:38, Vicente J. Botet Escriba wrote:

...

Hi,

I would like to merge some fixes in Boost.Thread, but I suspect that the release branche should be blocked as for https://svn.boost.org/trac/** boost/wiki/ReleaseSchedulehttps://svn.boost.org/trac/boost/wiki/ReleaseSchedule .

On which stage (milestone) is the release process?

It isn't on any stage. No one's currently working on a release, and it's looking very unlikely that it will happen before C++Now.

I was asking because after this page https://svn.boost.org/trac/boost/wiki/ReleaseSchedule the release should in Beta release. Best, Vicente Release Dates * First Monday in February * Last Monday in April (i.e. a week early to allow extra time before BoostCon/C++Now!) * First Monday in August * First Monday in November Release milestones *Note well: Changes must always be committed to trunk and be stable on trunk regression testing before being merged to branches/release.* * Upon release shipment: branches/release open 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 only 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. * Seven weeks before release: Release managers begin QA checks on snapshot doc builds, inspect status, getting started guide, and install. * Six weeks before release: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. * Five weeks before release: branches/release closed for all changes, except by permission of a release manager. * Four days before beta release: branches/release closed. Release managers begin building release candidates. * *Four weeks before release: Beta release. * * Upon Beta release: branches/release open for bug fixes and documentation updates. Other changes by permission of a release manager. * One week before release: branches/release closed for all changes, except by permission of a release manager. * Four days before release: branches/release closed. Release managers begin building release candidates.