Boost logo

Boost :

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-05 01:43:30


"Robert Ramey" <ramey_at_[hidden]> wrote in message
news:f1gnvf$bv8$1_at_sea.gmane.org...
> 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?

>>Formalization of
>> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk