On Sun, Jun 03, 2007 at 06:35:29PM +0300, Peter Dimov wrote: [snip]
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.
Agree, each component C's headers should be accessible only via an include path boost/C for the same reason that boost as a whole is meant to be accessible only via boost/. There has been spotty discussion of this as it relates to source control in the subversion threads.
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.
Agree. If you organize projects correctly you can get help managing/enforcing these dependencies. A library's headers, source, test, need to be together in source control (in one directory) so it is easy to version them independently. Projects have: (in directory BOOST_ROOT, say) iostreams/ include boost/ # contains only dir 'iostreams' iostreams/ *.hpp # notice each project has its own include dir src/ ... test/ ... variant/ include/ boost/ # contains only dir 'variant' variant/ *.hpp test/ ... If a component lists its dependencies as DEPENDS(iostreams variant) then BOOST_ROOT/iostreams/include and BOOST_ROOT/variant/include are added to the compiler's search path when it is built. Same thing happens at link time with whatever libraries the dependencies provide. This forces component authors to maintain their dependency lists... otherwise their component won't compile. It does not force authors to keep their dependency lists neatly pruned, but oh well. The dependency tree is easily accessible to automatic tools. However it is somewhat harder to navigate the sources.
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.
It becomes very easy to do many of the things in Beman's document, like back out changes in a library high (low?) in the dependency tree that break everything else, create arbitrary subdistributions, and incorporate new libraries into stable releases. The interface is straightforward enough that users developing boost-dependent code can easily manage their dependencies. Things can get tedious when several libraries become coupled, and in order to work on a 'branch', you must branch each of the individual components.
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.
Yeah, I imagine you could get as fancy as you want here. -t