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

From: Emil Dotchevski (emil_at_[hidden])
Date: 2008-07-15 17:32:28

On Tue, Jul 15, 2008 at 2:50 PM, Robert Ramey <ramey_at_[hidden]> wrote:
>> Boost Function changed between 1.35 and 1.36, both in terms of its
>> interface and semantics. The new allocator support is better but we
>> know it is a breaking change.
>
> If this indeed occurred, it was an error on the part of the author
> and he's just told users - "you're all working for me now".  Not
> a smart move if he wants to see his library widely used.

You have to strike a balance between breaking user code and improving
the interface of a library. This is particularly important for
interface changes that enable better implementations.

In the case of boost::function, we guessed that the change is unlikely
to affect many people. Nevertheless, you are right -- it's unfortunate
that the affected users have to make changes in their code, but it
would be even less fortunate to be stuck with the old interface, IMO.

>> Another example, shared_ptr now supports
>> aliasing, which means that other Boost libraries that use aliasing
>> can't be tested against 1.35.
>
> aaaaa - other boost libraries which used alias before it
> was implemented in shared_ptr.  That would be quite a trick.

No -- other Boost libraries which use aliasing before it was *released*.

Boost Exception is an example of such a library: it does not compile
against 1.35, precisely for this reason.

>> Had boost::function and boost::shared_ptr been frozen, we wouldn't
>> have been able to make these improvements. If I have to pick between
>> the improvements and the benefits of freezing these two Boost
>> libraries in particular, I choose the improvements (with all the
>> consequences, including release and testing difficulties.)
>
> oh - don't forget about the difficulties of your current users who
> now have to adjust their apps to accomodate a new library interface.
>
> This is an error.  If you want new semantics/interface - give them
> new names and leave the old one's in.

That's not always preferable.

>> For your approach to be
>> practical, we need more formal classification of changes, I think.
>
> We only need two classificaitons:  Either a change breaks
> interface/sematics or it doesn't.  Every change fits into one of
> these two clasifications.

Alright, so we have two classifications. But if the classifications
are not formal, you have the current situation, which is that
libraries change -- not without a notice, but often that notice is
limited to a SVN commit comment. It is unsafe to assume that such
changes don't break interfaces or semantics. I've already given two
examples; another example is boost::filesystem, whose interface
changed too (both in terms of interface and semantics); also
boost::thread changed recently.

You're arguing that we mustn't be making breaking changes, and I'm
saying that sometimes we do make breaking changes. These changes
haven't made Boost less useful for me, on the contrary -- I welcome
the improvements.

We need a system that can deal with this reality.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode