On Tue, Jul 15, 2008 at 10:12 AM, Robert Ramey <ramey@rrsd.com> 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