Subject: Re: [boost] El Capitan issues (Was: [1.61] Two weeks remaining for new libraries and breaking changes)
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-02-16 14:45:18
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
If I'm working on library A and it depends on library B, I'm looking at
library B's documented API. This is on the master branch. I can't know
what the developer API is thinking. Unless I'm in some sort of intimate
contact with him, I can't know what features he's including that I need
to use right now.
> I think this
> situation is far more likely than code in one library in the 'develop'
> branch having to wait until code in another library it may depend on is
> promoted to the 'master' branch of that library.
I disagree. see above.
This situation occurs on a regular basis. It's the situation right now
as I write this. Date/Time library uses the serialization library which
uses spirit/classic which now has a bug so it's holding up testing on
serialization, date-time and any others which include serialization support.
> Therefore while I
> understand the greater stability of testing the 'develop' branch of a
> library against the 'master' branch of all other libraries I am opposed
> to this sort of testing as a practical regression testing solution.
> Ideally we should have a testing system where one could specify for any
> given library its library dependencies, and one could also specify which
> branch of each library dependency we want to test against. But we are a
> long way from such a system at present.
I don't think that this would be worth the effort required.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk