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

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-07-15 15:40:59

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.

>Then you can (actually, should)
> test against any/all versions (which isn't unlike using STL.)

Hmm - I don't understand this.

>> b) Changes on the trunk affect other libraries.  Currently
>> we have a situation where a change in config breaks
>> a serialization jam fie.  OK so we fix the jamfile in the trunk.
>> Now we merge into the release.  Uh-breaks again since
>> the config changes aren't merged into the release.  OK
>> we'll roll it back.  Now the config changes are merged
>> into the release. Damn, breaks again.  OK merge
>> the jamfile changes from trunk - again.  Obviously this
>> is a huge waste of time.

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

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

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

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

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.

Robert Ramey