Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2008-08-27 09:51:24

on Tue Aug 26 2008, "Robert Ramey" <> wrote:

> David Abrahams wrote:
>> on Tue Aug 26 2008, "Robert Ramey" <> wrote:
>> 2. Robert, you're sounding a lot less flexible about this than you
>> ended up being in this thread:
> I've that in some cases its unavoidable.


> My problem is really the idea that breaking an interface is OK
> and normal. With a library in wide use, this creates a lot of
> new work for hundreds, thousands, tens of thousands? of people
> and prevents or delays users from upgrading until they can find
> time to put in that effort. Developers who engage in this practice
> will find that they lose users. To obsolete all the code that uses
> a library is a very costly decision which I believe developers don't
> take seriously enough.

Yeah, but my point is that with very few exceptions, you're preaching to
the choir by making your case here, and you're not giving your fellow
Boost developers enough credit.

If you know of cases where people broke backward compatibility in ways
that were irresponsible, it would be good to hear about those. And it
wouldn't hurt for Boost to have a guidelines page on how to manage
interface evolution. I might just write one.

> I drive an 11 year old Ford Taurus. I just had new spark plugs
> put in it. Imagine how I would feel if I was told - we don't make
> spark plugs for that model any more. The new design is much,
> much better. What do I do - replace the engine?

That's a false analogy. If you tried to upgrade the engine and you were
told "the new engine isn't a drop-in replacement for the old one; you'll
need $2000 in additional parts and labor just to get it hooked up" it
would be much more apt.

>From my point-of-view, it seems reasonable. Car makers don't preserve
backward compatibility every time they come out with a new part. Can
you imagine if Ford felt constrained to make all the parts in your
Taurus work in a model T?

> I understand that we want to make our works of art perfect.
> And its really, really annoying to live with a mistake knowing
> that we could have done better. But its self indulgent not to
> consider the impact of those who are counting on you to
> deliver the benefits of using your library. I'm sure that lots
> of projects are stuck with boost 1.33 because of this problem
> and I think that's a shame.
> And the most annoying thing is that many times its not
> really necessary. A new name could be created. Not
> as aesthetically pleasing perhaps, but still very effective.
> So, I think this is done more often than is really necessary

By whom?

Dave Abrahams
BoostPro Computing

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