From: David Abrahams (dave_at_[hidden])
Date: 2006-05-09 07:17:52
Darren Cook <darren_at_[hidden]> 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
"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
"fluid" == whether we should have such a category is open to
header-only vs. compiled
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk