On Tue, Jul 15, 2008 at 10:29 PM, David Abrahams <dave@boostpro.com> wrote:
I was talking about relying on dependent libraries catching bugs in a dependency (e.g. serialization's tests uncovering breakage in type traits). Sounds like you're talking about the other direction, sort of.
I agree that we don't want to rely on dependent libs to catch bugs in a dependency, but sometimes this does happen. When a serialization library test fails, we can't without further investigation assume that some other library is to blame, even if the serialization library tests pass with the last and the next release of Boost.
For example, you might depend on an implementation detail of another library without knowing it (note that "not knowing it" isn't always a matter of being careless.)
It isn't?
Not always. For example, the dependency may be indirect, through another library. Or, it might be due to buggy or incomplete documentation.
This might become source of regressions, which are typically undetected until the implementation of the dependent library changes.
Sure. What's your point?
That it is a bad idea to avoid testing an (even stable) library against the (unstable) trunk just because this may produce bogus failures. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode