From: David Abrahams (dave_at_[hidden])
Date: 2008-07-16 15:50:44
on Wed Jul 16 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
> David Abrahams wrote:
>> Most developers don't break interfaces lightly, but occasionally a
>> breaking interface change can be better for the overall health of
>> At least two of my libraries have had a ground-up redesign
>> since they were accepted into Boost and I believe that they are
>> better, easier to use, and the revision produced minimal additional
>> frustration or effort for users.
> Hmmm, I wasn't aware of this. It this redesign redefine existing
> interface/semantics or define new ones. Did an attempt to
> compile an old program fail with some sort of indication.
No, I started by deprecating the old interface and left it in Boost for
at least one release with a notice that things would be changing.
Usually I'd manage to keep the new and old interface around
simultaneously for a couple of releases. However, holding on to the old
library indefinitely would have been utterly impractical, not least
because I don't have time to support obsolete code.
> I don't think boost is a big offender in this area. Generally when
> it has happened the past, is usually a mistake or unavoidable. I also
> believe that the boost testing process - though I have my complaints
> about it- is very helpful in limiting this situation.
> I guess my position is I recognise that breaking interface/semantics
> is sometimes unavoidable. I just think that the repercussions
> are taken way to lightly by many developers. I also believe that
> its often done when not really necessary.
I think if you took a careful look at the history of breaking changes
that have caused disruption in Boost, that they have been caused by a
small subset of the subset of developers with disproportionately
depended-upon libraries. That is, a small minority of developers
operate that way, but when many libraries are depending on one of those
people for stability, it can make a big mess.
>> Also, avoiding all interface breakage may restrict a developer's
>> flexibility more than you imagine. Consider:
>> * Adding an optional argument to a function or an optional class
>> template argument, which should be a non-breaking change for most
>> everybody, can break user code.
>> * Adding an overload can break user code.
>> * Adding a new name to a namespace can break user code.
> I"m sure I could do all of these things.
I'm not sure what you mean.
> Generally I would consider it a bug.
In your code or the user's? If yours, are you seriously willing to say
you won't introduce any new functions or types into an existing
> I concede that in such a case I mght want to make different
> kind of change - but it hasn't happend yet.
>> * Will you continue to support MSVC6 et al forever? :-)
> LOL - now that is a very interesting new topic.
Not entirely new. If you drop support for MSVC6, you have made a
breaking change for some users.
> I would say I intend to support MSVC6 as long as it cost me nothing to
> do so.
So if it began to cost you something, you'd drop support even though it
would be a breaking change for some users?
-- 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