Darren Cook <darren@dcook.org> writes:
One of boosts roles is to do research and development, the other is to establish existing practise. The R& D role inevitably results in the need to break an existing interface in the interest of providing a better one, however that is inevitably not going to go down well with existing users. Establishing existing practise demands a high level of stability. Perhaps there needs to be a clear policy on the procedure to follow to go about modifying the interface ...
There has been talk about splitting boost into more manageable chunks for a long time and that seems to an ideal split line:
stable: interface will never change; only bug fixes in future
experimental: interface may change in a subsequent release
Requirements for stable could be: no changes in at least 6 months and author(s) having no intention to make changes.
We'd have to release a lot more often to make that meaningful. Anyway, it seems like "no backwards-incompatible changes" is a more reasonable definition of "stable." I don't much like the term "experimental." By the time a Boost library is released it should be in a state where backwards-incompatible changes are avoided with extreme prejudice and it has, in principle, been shown to have an interface worthy of preserving. IMO, the review process _ought_ to (and does, for the most part) weed out libraries that are truly "experimental."
If an author wants to make backwards-incompatible changes to a stable library they make it a new library, with a new name (even it just tacking "2" on to the end of the existing name). This should of course happen very rarely.
A note from my experience: I completely rewrote Boost.Python at one point and gave it a totally new and improved interface. It was announced well in advance (in fact the files coexisted with the old version in Boost CVS HEAD for a long time during development) and the result was called Boost.Python v2. The old version of Boost.Python was archived at that point and the archive was in the Boost distributions for a few releases before finally being pulled. I had no complaints about this change, IIRC.
Having a stable core will give developers more confidence in using boost for important projects; I think it is essential.
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 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. header-only vs. compiled ... -- Dave Abrahams Boost Consulting www.boost-consulting.com