Robert Ramey
I think a better way to look at Boost is a collection of more loosely coupled software components. The only coupling is to a minimal set of of practices and requirements: Compatiblity with C++, Formal Review, directory structure, and documentation requirements. In this view, there is no place for requiring a specific library for testing, requiring that some particular version of C++ not be supported.
For this we need a process of independent boost.XXX library version-ing and release procedures/schedule.
c) I have my whole boost development tree to set to master branch so I'm testing against the next release. Only the serialization submodule is set to develop (or a feature branch).
Unfortunately this is not the way test runners operate
d) Almost most all code is C++11/C++03 agnostic.
e) Some code is C++11+ specific. This is conditioned with BOOST_NO... macros. Some tests are conditioned on these macros as well.
In few cases this can work out like this. In many other cases maintaining c++03 compatibility can make library obsolete(I am not talking about my library). C++11/C+14 modern C++ code can and *should* look significantly different, with different API and implementation
If the author of Boost.Test feels he can't support older compilers, that's his decision of course. But he should be aware it's going to cut his "market share" and encourage the usage of alternatives.
This statement is conditioned on several big IFs IMO, but I am not going to argue. Gennadiy