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