Boost logo

Boost :

Subject: Re: [boost] Breaking existing libraries
From: David Abrahams (dave_at_[hidden])
Date: 2008-11-21 11:59:58


on Fri Nov 21 2008, Richard Hadsell <hadsell-AT-blueskystudios.com> wrote:

> Dave Handley wrote:
>> I'm going to have to very strongly disagree here. Depending on the usage of boost,
>> checking a new version is often not a trivial process, and the vast majority of
>> companies have other priorities for their software developers. My last company
>> worked in shrink-wrapped software, and we had a policy that we would tag the new
>> versions of all libraries just after our major annual release to give plenty of
>> bed-in time before our next major release. In my current job though, using a new
>> version of boost involves rebuilding an entire library stack, some of which is
>> outside our direct control. Also stability is highly important, much more so that
>> working on the latest and greatest. Therefore, we have a tendency to move to the
>> latest version of boost when we actually need a new feature. As such we've skipped
>> 1.30, 1.31, 1.32, 1.34, 1.35, 1.36.
> I totally agree with this.
>
> Furthermore, Boost's current beta release schedule would only find
> bugs. It would be too late for beta testers to argue against
> intentional changes in the libraries.
>
> Boost libraries should either maintain backward compatibility or mark
>themselves with a "user beware -- for experimental use only" caveat.

Of course backward compatibility is desirable, but maintaining it
rigidly prevents forward progress. Judicious breakage does not
necessarily mean that the library is "experimental" in any meaningful
way. Nobody really has a problem with the stability of shared_ptr, for
example, and yet look at its list of breaking changes over the years:

  http://www.boost.org/doc/libs/1_37_0/libs/smart_ptr/compatibility.htm

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk