Boost Testing :
From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-05 01:43:30
"Robert Ramey" <ramey_at_[hidden]> wrote in message
> Gennadiy Rozental wrote:
>> "Robert Ramey" <ramey_at_[hidden]> wrote in message
>> This doesn't address neither testing against new version of your
>> library by developers of other libraies
> Sure it does - they can either test against the HEAD as they do now
> or they update their local installation
Who is going to do this? Regression testers?
>> nor dealing with testing
>> agains updates of component your library depends on.
> This amounts to using the tests for one library as tests of the
> dependent library. There are two problems with this. First
> its very inefficient and arbitrary as the tests in my library aren't
> presume that the rest of boost works so they aren't designed
> to test the rest of boost. And if an error occurs then it has to
> be determined which of the components, libraries, build
> system, etc which are simultaneously changing is the cause
> of the failure. This wastes huge amount of time.
> That being said. If the rest of boost things that the serialization
> library is a good way test the other libraries - fine with me. Its
> not an issue for me at all.
I am not sure how your reply relates to my comment. What I meant is: How can
YOU test that your library works with the next version of let's say
Boost.Test I am planning to include into next release. Let's say I do my
development in branch new_dev. How could you test your lib against this
branch, but allow all other libraries still to be tested against HEAD?
>> independent versioning should allow us deal with it.
> I think boost as a concept has to change from tightly
> coupled group of "standard" libraries to a loosely
> coupled group of "interoperable" libraries. At its core
> I think this is the issue. Good news is that its not something
> that we have to agree upon. Its happening now as it
> must as boost get beyond the scale where it can be
> digested as a whole.
This comment I completely agree with. I just porpose how add some
formalization to this process.
> Robert Ramey