|
Boost : |
From: James Sharpe (james.sharpe_at_[hidden])
Date: 2008-03-13 10:34:55
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?
James
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk