Re: [boost] [filesystem][program_options][serialization][test] fromcomp.lang.c++.moderated

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
    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