Hello, very good point starting this discussion. From: "Beman Dawes" <bdawes@acm.org> 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