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

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-07-16 16:27:29

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.

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.

> 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.  Generally I would consider
it a bug.  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.

I would say I intend to support MSVC6 as long as it cost me nothing to do 
so.

Stripping out some of the stuff which supports MSVC6 would make the 
implemenation
somewhat cleaner.  But it would require a whole new round of testing 
compiler
by compiler and the net result would have nothing more than we have now.  So
there's no bang for the buck.

Borland 5.64 is another case.  Turns out the borland library would pass all 
tests
if two compilation bugs were fixed. I would like to do that - (bang for the 
buck)
but haven't been able to get my bjam setup working for borland.

The borland serialization library is also very interesting in this context 
as well.  When
spirit moved to 1.8 from 1.6 borland couldn't compile the xml_?archive (the
lastest version of borland still can't).  Getting xml_?archive to work with 
borland
was toture with spirt 1.6 - there was/is no way that I'm ever going to do 
that
again.  The developer's of spirit had the visiion (I guess they took the 
pledge)
to leave spirit 1.6 around.  So I stil only have one xml_?archive code base
which works with both spirit 1.6 and spirit 1.8.  Now THAT's professional
software development which we should all be aiming for.  I believe that
the authors want to make some interface/semantic changes in the old names
and they've announced that.  I can live with this - using conditional 
compiles -
but it would be preferable to use new names.

I'm getting off the topic of my proposal for "sugical testing" vs "carpet 
bombimg testing"
but this is an interesting topic for me.

Robert Ramey