"Robert Ramey" <ramey@rrsd.com> writes:
The other scenenario. Author A makes his changes and runs his tests and things are great. Unbeknownst to him, he has changed the public interface, by enforcing a previously unenforced interface requirement (I did this once) and of course he doesn't notice as his tests run. At this point the changes are merged into the next release and stuff in other libraries break. This is not the case where the maintainer of A is AWOL its just a normal fiasco which has to be resolved in the usual manner.
So I would refine the proposal somewhat to
a) development and tests are run on a branch (for that library) b) when its time to merge tests are run next release branch with the library switched in. That is, one can run the test with all of boost BEFORE the library is actually merged in c) If b passes then the changes are merged into the release and all tests are run again just to make sure.
The issue is what to do if b) fails with an error in library B. Author A has just made a change that breaks another library (even if the other library was depending on something it shouldn't have done). If author B cannot or will not fix the problem, what do we do? What if the change makes library B unusable? Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL