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