Re: [boost] Boost 1.36 planning

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-03-14 03:10:06

From: "James Sharpe" <james.sharpe_at_[hidden]>
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