From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-03-27 16:55:22
very good point starting this discussion.
From: "Beman Dawes" <bdawes_at_[hidden]>
Subject: [boost] [1.36.0] Suggestions for 1.36.0
> While the 1.35.0 experience is fresh in my mind, I've jotted down
> suggestions for the 1.36.0 release process.
> See http://svn.boost.org/trac/boost/wiki/SuggestionsForOneDotThirtySix
> Comments welcome,
Some suggestions and questions follows.
* Start work on the next release as soon as the current release ships.
Could some one explain what is the probleme to start before?
Why not to limit the contents of the next release to the libraries already
accepted and ready to be released 3-4 months later? The other could be
released 6-8 months later.
What will be the cost to release a bug-fix release every month?
* Feed trac bug reports into the regression reports, so that outstanding
tickets for the release-in-process are more obvious.
It will be useful if associated to the bug reports there is a test that
check the new code correct them.
* Recognize that infrastructure changes (new Boost.Build version, new
testing procedures, new web site organization, new directory tree
organization, etc.) have a history of being very disruptive and markedly
slowing release progress.
* Test and debug such changes on a branch before inflicting them on the
* Make sure developers are educated as to the impact of such changes.
Maybe the test and debug in this specific infrastructure branch could be
considered as a intermediate release, with all the quality constraints of a
release but without any new library or new feature on the existing library,
This way we separate infrastructure and feature releases. A feature release
is based on a given infrastrure release.
Vicente Juan Botet Escriba
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk