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