Boost logo

Boost :

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
    newer ones.

    "fluid" == whether we should have such a category is open to
  header-only vs. compiled


Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at