But I don't know. Here's another idea. Rather than trying to make the analogy between boost and a single open source project, perhaps the analogy should be between boost and a single distributer of multiple open source projects, for example, Debain or Fedora. Debian, for example, has three tiers of "release": testing, stable, and unstable - everyone's favorite. ;) I'm not sure what quality control procedures they have, but maybe that's also a good place to look for ideas.
I think a better view of what boost should be or actually is is a collection of compatible libraries. One "model" which I presumed inspired boost is STL (std:: namespace) which included a large collection of parts which would work together. I think that one view of boost is STL++. Totally understandable - but I don't think its the best way of looking at it. I think that boost is "looser - more decoupled" group of facilities than STL is. I would think that in the future boost would move toward something that looked like the following: a) directory structuring & namespaces .../boost /serialization /include ... files /lib src build .. etc b) versioning each library having its own version number c) requirements each library lists the other libraries it depends upon and the minimum version # - as it does with compilers now d) release "library release" would be considered effective when any changes in the trunk are merged into the release branch and nothing breaks. "boost release" would contain the lastest release version of all libraries e) testing testing of each library would be done against the current latest release versions. Optionally, a user could run tests for any specific library against his "manifest" of the the library versions he uses. He might want to do this if he didn't upgrade all the libraries he uses but only a few. Robert Ramey