Vicente J. Botet Escriba
Le 14/01/15 18:10, Raffi Enficiaud a écrit :
I suggest you to : * rollback your changes related to Boost.Timer, this should make all the libraries to work as before.
done. I tested thread locally and it should work in its current state (no need to roll back anything).
* create a branch on which you move to the new Timer interface and you maybe need to link to (it would be preferable to don't need it). * Announce the breaking change on this ML (yes there is a breaking change if the user needs to link to Boost.Timer and didn't needed it before). * If the breaking change is accepted, propose PR for each one of the libraries :(
I understand that this is more work than breaking all the users code, but at the end you will gain.
well, I am not afraid of work, but since boost.timer new API depends on chrono, this change will not going to happen any time soon, as it breaks the “header only boost.test” contract. Also, breaking the code of others was, of course, not exactly the goal I was aiming for.
HTH, Vicente
P.S. I don't know what is the state of the Boost.Test develop branch, but if I were you (I'm not) I would follow the advice given by others in other threads: * Rename the develop branch to a feature branch. * Create a develop branch from the master branch. * Fix the major issues on the develop branch in parallel with the development of the new big feature. * When the feature is ready, merge it to develop and then to master.
The problem we encountered are not related to the way we are branching. OTOH creating a feature branch would not have tell us/me the problems encountered *before* the merge to develop/master. It is always possible to run the tests for the full boost locally, but this takes ages and for some reason some tests are getting stuck on my machine (I have to kill the processes manually). But I’m learning to use the tools provided by boost, and hopefully I will learn fast. Best, Raffi