Hello,
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Tuesday, May 09, 2006 1:18 PM
I agree with that; no question about it. I think a few more degrees of classification than you've outlined could be useful:
core vs. optional
I hate "optional" but can't think of a better term right now. This is the distinction between, e.g., type traits and serialization
I think, the distinction between 'boost.core' and 'boost.optional' (or 'dependent' or sth.) could also be useful to release the strong requirements concerning dependencies between boost libs. While core could still be (almost) free of lib interdependencies, 'optional' libs could freely link to others (possibly even third party, i.e. XML parsers etc.). IIRC, property tree was critisised because of its dependencies, but when libs get more complex (and more directly related to applications), such dependencies may be inevitable and even useful, while it's still nice to have a core of independent libs.
fluidity
"frozen" == Only bugfixes, in principle. A library can move out of "frozen" to stable at the whim of its maintainer.
"stable" == Only bugfixes and extensions.
"active" == backwards-incompatible changes avoided with extreme prejudice, and made only after one release of deprecation. A strong bias is given towards preserving availability of old interfaces under the same name, even if they've been superceded by newer ones.
"fluid" == whether we should have such a category is open to debate.
Sounds like a lot of work for the maintainers and the release managers. Maybe it would be sufficient to let every lib have ist own version (aside from the boost version) and use the usual versioning scheme, where changes of the minor version denote downward compatible APIs while new majors indicate API breakage (versionwise). Just my 0.02EUR as a lurker. cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | ames AT avaya . com