On Tue, Jul 15, 2008 at 2:50 PM, Robert Ramey <ramey@rrsd.com> 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