Re: [boost] Boost Development Environment proposal

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-06-03 11:35:29

Beman Dawes wrote:

> There is a fresh draft of a Boost Development Environment proposal up
> at http://mysite.verizon.net/beman/development_environment.html

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.

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.

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.

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 
.34.zip. The installer probably ought to also allow upgrading a single 
library (or adding a new library) should the user so choose.