"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote in message news:e3vl3p$hd7$1@sea.gmane.org...
"Beman Dawes" <bdawes@acm.org> wrote
The problems with the current release approach are not caused by release managers or developers, but rather by the release system itself. It just doesn't scale up to the number of libraries now in Boost, since every library has to be ready before a release can occur.
These problems will only grow worse as more libraries are added.
I think you are considering just one dimension of the problem.
Yes, and that is deliberate.See below.
The other one -- the number of supported compilers is IMO equaly, if not even more, important. The broken build can be detected only after the regressions run on all the compilers. Which may be a few days (or a few weeks). To fix the build would require a few more regression cycles, and by that time new errors can (and most likely will) be introduced.
Something needs to be done about compiler availability -- this is the most critical issue, IMO.
Testing issues such as what compilers to support abd/or require are certainly important. Distribution issue (subsets, binaries, etc.) are also important. If we try to fix all problems at once, I am afraid we will bog down in details. IMO, the several dimensions of the general release problem are separable. Hence the focus on fixing the release model as a separate task. Thanks, --Beman