On 2/16/16 11:30 PM, Andrey Semashev wrote:
On 2016-02-16 22:45, Robert Ramey wrote:
On 2/16/16 11:08 AM, Edward Diener wrote:
Sorry, the suggestion is that on the develop test matrix, each library be tested on the develop branch against the other libraries on the master branch. This would permit a developer to make an innocent mistake without bringing down the whole system.
This creates a problem when code in one library in the 'develop' branch depends on code in another library in the 'develop' branch.
I think this is an exceedingly rare occurrence and I doubt that it ever happens.
Just recently I've had another case of synchronized update of multiple repositories on develop.
https://github.com/boostorg/winapi/pull/20 https://github.com/boostorg/dll/pull/7 https://github.com/boostorg/dll/pull/8
Such situations appear more often than you think.
another case? Looking at this particular case I think "exceedingly rare" is still an accurate characterization.
In general, I want my develop code to be tested against develop of other libraries to be able to detect failures before they get released.
When something in your library fails, how do you know whether it's in your library or some other library you depend upon? It can take a huge amount of time to find an error in another library.
I wouldn't mind to have _additional_ testing against master of all other libraries.
This is currently easy to do on your own system. Just leave the modular boost superproject on it's master branch, checkout your particular library and switch it to the develop branch. Now when you run your tests locally, you'll be running against the (almost) known good master. So you can be (almost) certain that any problem is in your own code. In fact, I'm guessing that a lot of people are actually doing this right now without realizing it. The problem comes when they check in the develop branch and all of a sudden they're working with other peoples (possibly buggy) develop branch and things go haywire. Think of testing as a scientific experiment to prove/disprove that your latest changes are correct/incorrect. The experiment can vary only one variable at a time (your code). If you hold the other variables (other's libraries) constant , then your experimental results are very hard to interpret. This is bad enough. What's worse is that if I check an code containing an error into the develop branch, I generate a bunch of failures for other library authors. It makes me reluctant to add/change features. Robert Ramey