Re: [boost] [filesystem][program_options][serialization][test] from comp.lang.c++.moderated
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
"Ames Andreas" <Andreas.Ames@comergo.com> writes:
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.
I can't imagine why that would cause any work for release managers, and speaking personally, I wouldn't find classifying the fluidity of my libraries to be much of a hassle; it shouldn't take more than a few minutes. Changes in fluidity happen rarely, and frankly, I think choosing and publicizing categories would help me focus my maintenance decisions. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Ames Andreas" <Andreas.Ames@comergo.com> writes:
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.
I can't imagine why that would cause any work for release managers, and speaking personally, I wouldn't find classifying the fluidity of my libraries to be much of a hassle; it shouldn't take more than a few minutes. Changes in fluidity happen rarely, and frankly, I think choosing and publicizing categories would help me focus my maintenance decisions.
I agree. The "core/optional" distinction is more difusee, too much to be usefull perhaps, but this fluidity "tag" is a simple and good idea. As you and others pointed out backward-incompatible changes should be avoided real hard, and their impact studied and announced very carefully in case really needed. One should always consider branching a "new" library instead of breaking the version users are currently using. Also, at least for leaf libraries, like serialization, the mantainer can keep the old version in sync with latest boost. This way, users don't need to stick to an older "version of boost" (as a whole) but only to an older "interface-version" of a specific leaf library. That is, users could install the lastest boost and then "override" a leaf library with an "older-but-up-to-date" version of it. "older-but-up-to-date" means a library that is kept in sync with all of boost but which exposes an older interface. Of course this is not needed if the library interface evolved in a backward-compatible way. -- Fernando Cacciola SciSoft http://fcacciola.50webs.com/
participants (3)
-
Ames Andreas -
David Abrahams -
Fernando Cacciola