Ilya Sokolov wrote:
Robert Ramey wrote:
[snip]
I envision the following:
a) a "release ready" version branch or whatever. This version pass all tests or failing tests are marked up - its "perfect" (lol)
b) I make a change in my library, and test against the "release ready" version.
It is not clear to me who will test 'against the "release ready" version', you or testers? If testers, than you need one tester for each library and I don't believe boost have such resources.
OK - now we're moving beyond discussing the merit of the idea to discussion its praticality - a whole new discussion. Of course I'm game. On my own system there's no problem. I just have a "release ready" boost and run the tests on the compilers that I have. The issue is when I want to see tests run on other compilers. I would imagine a process similar to the following: a) I upload to the trunk. A tester runs his script. Currently the test script which syncronises his local system with the trunk and runs the bjam tests. In my proposal, the tester would maintain a "release ready version" on his machine. The script would do the following: a) determine which libraries have changed since the last time he tested. b) For each changed library: i) the equivalent of the SVN "switch" command would be invoked to sync up THAT library with the trunk. ii) bjam test script would be run for only that library. iii) After the test, SVN switch would be reversed. This would entail a lot less. Since one small change in a common header wouldn't trigger testing all the libraries. Futhermore - the testing could, and should be a lot more exhaustive than it is now. Here is a plug for my library_status program which produces a table for a library which includes ALL build configurations - not just debug with dynamic libraries. See www.rrsd.com (boost) for an example of the output this program produces. This helps address the problem where I test for debug - only but the program turns out to fail in release or some other build. This has been he source of much frustration with the serialization library. Now second phase. The release manager gives me permission to roll in my changes into the "release ready" branch. The testing is identical to the current system - there is no "SVN switch". The tester signs up for either trunk testing or for release testing - which is what he does now. In short, implementing this would require a different and more intricate trunk testing script. This is simple to state and to describe - but would in practice be somewhat tricky due to the following: a) Library code not found in one directory so doing an SVN "switch" is not just a one liner. b) I seems to me that an SVN switch in fact does a merger - which can lead to conflicts. And switching back might result in a change in the library. I suspect these issue could be addressed by more careful investigation of the details of SVN usage. So that is more or less how I would envision this testing program being implemented. Robert Ramey