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

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-07-16 17:53:21

>>> 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.

What I mean is that I could easily do all these things unintentionally

>> Generally I would consider it a bug.

In my code.

> 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?

>From time to time I would expect the library to be extended
by adding new functions and perhaps new types into an existing
namespace.  It has never occurred to me to that this could
break user code - but now that you mention it I suppose it could
if users had added their own stuff to the archive namespace.  However,
I would probably consider this a user error in that it violates
the intention of name spaces to avoid just this problem.

>> 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?

And of course, that would be OK. Even in this case I might want
to leave around the old version.  But, I guess that my pledge would have
to extended to cover this case.  On the other hand, the "pledge" is
mostly a retorical device to make a point so I'd rather not turn it into the
tax code.

Robert Ramey