Le 05/10/15 22:43, Robert Ramey a écrit :
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
LOL - That's my point exactly. And it is one of the sources of these problems. If things were run the way I suggest, you could make a temporary mistake in development of Boost.Test which wouldn't ripple though to all the libraries which use it for development testing. It would make your life a lot easier.
This is also what I suggested (I believe), and something we can envision: - cloning out full boost - checking out a particular branch (say "next") of eg. boost.test - running the runner with the source in place (using the --have-source switch) This builds will be triggered only by changes to boost.test[next], so that it will be boost.all against boost.test[next]. This will add several columns to the test dashboard. I think for libraries having a lot of children in the dependency graph, this would be very beneficial.
It makes no economic sense to go back and re-write working code to just because there is a new standard. There is no benefit unless one want's to add features. Some might say that it makes maintenance easier - but this is a decision that only a the library maintainer is qualified to make.
In this very case, the changes were also adding features. Best, Raffi