"Robert Ramey" wrote in message news:f1gnvf$bv8$1@sea.gmane.org...

Gennadiy Rozental wrote:

...

"Robert Ramey" 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