Halleluhuh!!! Here are my observations: Mostly minor quibbles "Objectives" "A developer may at any time request non-invasive tests of a library's development branch on any or all platforms against any stable branch of the other libraries. The non-invasive requirement ensures that problems in the development branch of the library being tested do not destabilize the stable branch being tested against. The on-demand requirement ensures that developers receive timely test results. Running tests against stable branches of other libraries ensures the tests are run in a stable environment." This section doesn't seem to belong to "Objectives" as it pre-suppose the solution described subsquently in "Policies". I think it should be move down to that section. "Policies" "Integration of a development branch into a stable branch only occurs after the integration is proven to be stable." When I first read the document it wasn't clear to me whether it referred to one development branch or one development branch for each library. I presume we mean the latter. (plus one each for bjam, quickbooks and ?, see below). "Reduction in tool fragility is a general goal, because tool fragility" Tools for build and testing should be part of the same system. Currently Boost Test is part of this system so that would be fine. Bjam.v2 should also be sjubect to the same procedure. Of course this would mean that tools like bjam and quickbooks should have their own test suites which can be run on a separate branch until they are determined to be "release stable". In other words, tools for building boost should be subject to the same standards and procedures that boost libraries are. "Scenarios" "A library has been modified and tested locally on a development branch, and needs to be tested on other platforms. These tests must be against one or more of the stable branches. Variation: the library is a dependency of other libraries, so they must also be tested to ensure they have not been broken by changes to the base library." I don't think this second sentence is correct. If a library is tested against the stable branch and errors are found, they are either in the library tested or in another library already in the stable branch. If its the former, the test fails and the library cannot be merged into the stable branch. If its the latter, the stable branch has a bug and it should be handled according to the procedure for that case. The developer of the dependent library has the choice to either workaround the problem or wait for the bug in the stable branch to be fixed. "A request for the latest snapshot of one of the stable branches." I don't understand what this means. "[A] Bug is found in one of the stable branches. The fix must be done in such a way that there is no possibility of the stable branch becoming unstable. This should be handled as any other case. The bug is already there and had been released. Its probably been there for a while so its not cropping up everywhere. That is its not any more urgent than any other enhancement or bug. So I would say that the correct procedure for addressing a bug in the stable branch is: a) open up the developement branch. b) make up a test which traps the bug and add the test to the library's test suite. c) Continue as with any other library enhancement. Thus, though we can't guarantee perfection, this will guarentee continuous improvement. "A new release of a ccompiler breaks existing libraries." "A new release of a non-critical compiler breaks existing libraries." "A library wishes to support a compiler that is not on the "release-critical" I think the whole concept of classification of compilers is sort of red herring and adds work and complication in an attempt to address an unaddressable situation. Suppose we have two libaries a) boost.lambda - it unrealistic and unproductive to use this library with an older compiler. This is not a problem as no reasonable person is going to expect or attempt to do this. b) boost serialization - this library supports borand compilers back to 5.51. And some users find this useful. And it doesn't cost anything to leave it in. So don't see where a boost wide concept of "release critical" compiler can be defined. Boost already has the policy that code should compile on a standards conforming compiler and that it shouldn't be rejected if a some inconformant compiler (basically all f them) can't compile something in the library. So I would suggest that each "stable" version has matrix which for every combination of library/compiler shows support or non-support. Actually we already have this in the test matrix. So when a new release of compiler x comes out, there is nothing urgent to do - nothing is "broken" its just that that compiler support boost only up to "version xxx" ( more on that later) until library developers get around to catching up. "A library is to be separately released. This separate release is to include both the library and its dependencies" The desire or percieved necessity that a library needs to be separately releasable should be seen that the library developer has found the system lacking. That is, if the procedures realize the stated objectives, there should be no incentive to making a separate release. I envision that one might spend some time on the development branch and testing at home until things are as perfect as I can make them. Then I request a test to check against the compilers I don't have. A couple of iterations on that and now I as to be merged into the stable branch. Things should pass. (Since we've already tested my changes, we're just re-running the tests on all the other libraries so the only surprises should come in libraries which depend on mine if and only if I broke an interface). At this point the "stable" branch is a "guarenteed improvement" so there is no point in NOT releasing it" So I would expect a new "release" every month or so. So why would a developer go through the hassle of a separate release just get changes to users and average of two weeks sooner? Misceleanous The term "stable" bugs me. It suggests "good enough", "not getting worse" in general it pessimistic. I would prefer "release" or "release candidate" which I think is more accurate anyway. Robert Ramey Beman Dawes wrote:
There is a fresh draft of a Boost Development Environment proposal up at http://mysite.verizon.net/beman/development_environment.html