From: "James Sharpe" <james.sharpe@gmail.com> Subject: [boost] Boost 1.36 planning

Since the release candidate for 1.35 is now iminent might I suggest that its time to start thinking about appointing a release manager for 1.36 so that the next release management process can begin? There are a number of tasks that I'd argue can be done now - especially as subversion makes this process relatively easy to be managing multiple branches at once. I'm thinking tasks such as establishing supported platforms, integrating newly accepted libraries into the source tree could all begin to happen whilst the final touches are done to 1.35. Then as soon as 1.35 is released, regression testing can begin on 1.36 (as I know that testing resources are limited). This will also help gain some momentum in the release process as library developers can start targeting features towards the 1.36 release as opposed to just general library development with no foreseeable target. I believe that a stronger concept of a code freeze for new features should be employed to try and encourage a quicker release cycle, which should hopefully mean that there are less regressions to deal with as new features will be tested more thoroughly and not left as test failures for so long as they might otherwise be.

As a result this suggestion would mean that a release manager should never manage two releases in a row, as it would require some overlap at a particularly crucial stage in the release process, which I think will work well and it also means that should bug fix releases e.g. 1.35.1 be required then the manager for 1.35 would be able to coordinate that without adding any delay to the 1.36 (which will be tracking any bug fixes from 1.35 via the trunk). Note that the other advantage is that release tool development can occur in parallel as problems are found - there was a discussion some time earlier about a suggested tool update(I don't recall what it was now - may have been docs related) which was dismissed as 'lets fix it when 1.35 is done' whereas I think that the correct response should have been 'that can be developed on trunk(or release branch 1.36)'

Thoughts?

Hi, This is an excellent idea. I would add also that, in order to reduce the release time cycle, only the libraries that have been accepted before the manager annonce the starting of the next release, should be candidates. There are already 10 accepted libraries that could be candidates *Floating Point Utilities Johan Råde February 27, 2008 *Flyweight Joaquín Mª López Muñoz January 30, 2008 *Factory (fast-track) Tobias Schwinger December 21, 2007 *Unordered Containers Daniel James December 16, 2007 *Forward (fast-track) Tobias Schwinger December 7, 2007 *Exception Emil Dotchevski October 7, 2007 *Time Series Eric Niebler August 13, 2007 *Math Toolkit John Maddock April 27, 2007 *Quantitative Units Matthias Schabel April 4, 2007 *Accumulators Eric Niebler February 7, 2007 There are 2 accepted provisionally libraries that could be candidates after complete acceptation *Switch Steven Watanabe January 13, 2008 *Globally Unique Identifier Andy Tompkins May 10, 2007 There are 2 review pending libraries *Logging John Torjo February 13, 2008 *Scope Exit Alexander Nasonov August 22, 2007 And one ongoing that should be accepted *Proto Eric Niebler March 1, 2008 - March 31, 2008 Sorry if I have forgotten a library. Of course the other libraries that are already in the review schedule should be also interesting if accepted, but IMHO it is preferable to reduce the release cycle. This will be not a problem for the libraries accepted after if the release cycle is reduced. Note also that even if a library is accepted this do not means that the maintainer is ready to release it. It would be a good challenge to get the 1.36 release only six month after the 1.35 one. _____________________ Vicente Juan Botet Escriba