Re: [boost] [1.36.0] Libraries with unmerged changes?

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
>> software.
>> 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
namespace?

> 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