Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-06-04 10:10:27

Peter Dimov wrote:
> Beman Dawes wrote:
>> There is a fresh draft of a Boost Development Environment proposal up
>> at
> This is a very well thought-out piece. I see one minor problem with it: it
> depends on additional work from the developers, namely, explicit merge
> requests. I'm afraid that the principle of least resistance will result in
> work happening on -devel and -stable stagnating due to lack of merge
> requests. In a non-volunteer ogranization one will have the authority and
> means to enforce the procedures and prevent this, but I'm not sure about
> Boost.

The idea is that merge requests would be something as simple as sending
an email to some server which is running a script that automatically
checks that all criteria are met and then does the merge.

Hopefully that is easy enough that developers won't put off making

I personally find the current situation, with very long delays between
releases, to be very de-motivating. If releases are done on a more
frequent basis, that will be a strong motivation to request merges. But
we would certainly need to keep a close watch on the process as it gets
going, and make adjustments if developers aren't requesting merges when

> That said, it might be good time for us to radically rethink the structure
> of Boost and decouple versions from releases. Versions should be
> per-library, and releases should be a set of versions. This separation ought
> to be enforced on a directory tree level, as in:
> boost/
> foo/
> foo.hpp
> bar/
> bar.hpp
> with nothing else allowed in boost/. A separate compat/ directory would hold
> the current contents of boost/ (header name-wise), giving people a migration
> path.

There are additional reasons why we consider at least some change in the
Boost directory tree organization. I'll start a separate thread on that

> This should probably come with a stricter dependency management approach
> than the current "none". Each library should list its dependencies,
> per-library tests should operate on a subtree formed by the dependencies and
> not on the full boost/ tree, adding an additional dependency should be
> frowned upon. We might consider introducing "dependency levels" such that a
> level N library can depend on level N-1 libraries, but not vice versa.

I independently also came to the conclusion that "per-library tests
should operate on a subtree formed by the dependencies" and went so far
as to write a little program to assign dependency levels to libraries.
That has to be done on a library-relative basis so that cycles are dealt
with properly.

After some more thought, I decided that when a developer requests a test
(via the "test on demand" mechanism), it should be possible to request
tests on multiple libraries, so that a dependency sub-tree or any
portion thereof can be tested.

Rather than building dependency lists into the system (which is a fairly
heavyweight approach), it might be simpler to give developers a tool to
find which libraries are dependent on their library, and then leave it
up to the developer how much or little they test against the dependency
tree. If a developer who undertests runs the risk that a
merge-into-stable request will fail, because merge-into-stable requests
fail if they would cause any other library to fail.

> With this organization, several releases can proceed in parallel, it being
> the sole responsibility of the release manager to pick the correct library
> subset and their versions such that the result is a stable release. More
> importantly, it allows developers to concentrate on improving their
> libraries.
> Once there one could venture into the direction that packaging a specific
> release should be the job of the installer and not of the release manager;
> that is, Boost should package individual library versions, not a monolithic
> The installer probably ought to also allow upgrading a single
> library (or adding a new library) should the user so choose.

The larger Boost gets, the more attractive this approach gets. Are we
ready for it now? I don't think so. Should we be moving in that
direction? Yes! I think we should be thinking in terms of a development
environment organization that will support such a parallel development
and release mechanism. I'll update development_environment.html accordingly.



Boost list run by bdawes at, gregod at, cpdaniel at, john at