From: Ames Andreas (Andreas.Ames_at_[hidden])
Date: 2006-05-09 08:30:38
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] 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
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.
> "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
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.
-- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | ames AT avaya . com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk