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

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

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. Then you can (actually, should)
test against any/all versions (which isn't unlike using STL.)

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

Same with Boost Config: having a single configuration point is
convenient but the price of that convenience is coupling.

This is actually a good argument for branching the release branch off
of some version of trunk. Presumably, the tests on trunk reflect the
state of Boost in its entirety, dependencies and all.

I think that I understand the reasoning behind the separate release
branch. I think that it would work better if we had less coupling in
Boost (I'm not sure if that's possible/practical, though.)

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