Re: [boost] [1.36.0] Suggestions for 1.36.0

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-03-27 16:55:22

Hello,

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,
>
> --Beman

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 
trunk.
  * 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, 
only bug-fixes.
This way we separate infrastructure and feature releases. A feature release 
is based on a given infrastrure release.

Regards
_____________________
Vicente Juan Botet Escriba