From: Robert Ramey (ramey_at_[hidden])
Date: 2007-06-03 12:41:00
Here are my observations: Mostly minor quibbles
"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
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.
"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
development branch or one development branch for each library. I
presume we mean the latter. (plus one each for bjam, quickbooks and ?, see
"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
"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
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
This should be handled as any other case. The bug is already there and had
released. Its probably been there for a while so its not cropping up
That is its not any more urgent than any other enhancement or bug. So I
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
c) Continue as with any other library enhancement.
Thus, though we can't guarantee perfection, this will guarentee continuous
"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
I think the whole concept of classification of compilers is sort of red
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
And some users find this useful. And it doesn't cost anything to leave it
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
should be seen that the library developer has found the system lacking. That
if the procedures realize the stated objectives, there should be no
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
a test to check against the compilers I don't have. A couple of iterations
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
tests on all the other libraries so the only surprises should come in
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?
The term "stable" bugs me. It suggests "good enough", "not getting worse"
in general it pessimistic. I would prefer "release" or "release candidate"
I think is more accurate anyway.
Beman Dawes wrote:
> There is a fresh draft of a Boost Development Environment proposal up
> at http://mysite.verizon.net/beman/development_environment.html
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk