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

From: Emil Dotchevski (emil_at_[hidden])
Date: 2008-07-15 15:22:25

On Tue, Jul 15, 2008 at 12:40 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> Emil Dotchevski wrote:
>> On Tue, Jul 15, 2008 at 10:12 AM, Robert Ramey <ramey_at_[hidden]> wrote:
>>> Proposal:All tests for a particular library should be run against
>>> the latest or next release.
>>
>> This can't work if a library depends on a another library that was
>> changed. You'd be testing against the old version of that library,
>> which isn't very helpful (meaning, your code may be out of date and
>> you might not know about major problems until much later.)
>
>> Your proposed approach would work if we elect to freeze the interface
>> and the semantics of some libraries.
>
> EXACTLY !!!
>
> The whole concept of a library is that it has established
> interface and semantics that users of the library can depend upon.
> Without this, libraries are useless. One can't write code based on libraries
> whose interface and/or semantics are changing without notice.

If that was true, nobody would be using Boost. :)

It's a fact, Boost libraries evolve and interfaces and implementations
change all the time. You can argue that the changes are minor, but as
you know they're significant enough to break tests in other libraries.

For your proposal to work, we need a formal freeze for individual
libraries. Without this, all bets are off, as far as I'm concerned.

>> This is the effect of coupling.
>
> EXACTLY !!!
>
>> For example, the Exception library
>> depends on intrusive_ptr. The only way to make it not depend on
>> intrusive_ptr is to not use it (duh.)
>
> Nope - The exception library should depend upon the intrusive_ptr
> library interface and semantics which should never change.(duh.)

I am on the fence actually. It was a difficult decision for me, to
depend on intrusive_ptr. Ideally it wouldn't change but the reality is
that it might. And if Boost Exception wouldn't benefit from a future
improvement in intrusive_ptr, it's perhaps better not to depend on it,
given how simple it is to "reinvent the wheel" in this particular
case.

We have plenty of examples for Boost libraries changing for the better.

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. Another example, shared_ptr now supports
aliasing, which means that other Boost libraries that use aliasing
can't be tested against 1.35.

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

>> Same with Boost Config: having a single configuration point is
>> convenient but the price of that convenience is coupling.
>
> That is a very high a price to pay and should only be paid
> in extraordinary circumstances.  In this particular case, the
> change should have been incorporated in the "next release"
> then it would have been detected when the "next release"
> is tested.  At that point concensus would be built for either
> backing out the change, or rippling through the interface
> change to all libraries which depend upon it.  During this
> period - and only during this period - the "next release"
> would be unstable and not a candidate for a release
> package.

Yes, but you are assuming that since the period of unstableness is
limited in time, it's also limited in scope. For your approach to be
practical, we need more formal classification of changes, I think.

>> I think that it would work better if we had less coupling in
>> Boost (I'm not sure if that's possible/practical, though.)
>
> LOL - Boost and other libaries are successful in inverse
> proportion to the coupling to other libraries.

Boost is not a library, it's a collection of libraries. I'm talking
about dependencies between Boost libraries, not about Boost depending
on external libraries (à propos, one of the arguments against using
Boost is that it's very difficult to use this or that Boost library
without introducing a defacto dependency on all of Boost.)

> Suppose STL changed with every release - would it not
> be effectively useless?

No, but I agree that it would be a lot less useful.

Also, the price of the stable STL is that we have to live with its
problems. A good example is the broken allocator semantics of STL
containers.

> Obviously there will be rare occasions when interface
> and/or sematics of a library change (auto_pointer) when
> things like design errors are discovered. But these situations
> should occur only vary rarely.

The question is what to do when such changes in Boost libraries occur,
because the reality is that (very often) they do.

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