|
Boost : |
Subject: Re: [boost] El Capitan issues (Was: [1.61] Two weeks remaining for new libraries and breaking changes)
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2016-02-17 11:56:26
On Wed, Feb 17, 2016 at 10:51 AM, Robert Ramey <ramey_at_[hidden]> wrote:
> On 2/17/16 7:15 AM, Rene Rivera wrote:
>
>> On Wed, Feb 17, 2016 at 9:10 AM, Steven Watanabe <watanabesj_at_[hidden]>
>> wrote:
>>
>> AMDG
>>>
>>> On 02/17/2016 01:25 AM, Robert Ramey wrote:
>>>
>>>> On 2/16/16 11:30 PM, Andrey Semashev wrote:
>>>>
>>>>>
>>>>> 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.
>>>>
>>>>
>>> With the example I posted, that makes two
>>> of your "exceedingly rare" cases in the
>>> last week.
>>>
>>>
>> I also have another case that "came up" December/January involving close
>> to
>> a dozen libraries. But I created all the changes, and it was build system
>> related (i.e. changing build files). It hasn't made it to master yet. And
>> I
>> need to push it to master all "at once" (not looking forward to that).
>>
>
> right. And if you were doing it my way (assuming you aren't inadvertently
> doing this way already), you'd have much less anxiety about this.
Note.. I'm in favor of your idea of develop-against-master testing. But I'm
now thinking it's best to make it an option for each library as to what
mode they should be tested in. Of course I think the ideal would be to test
both ways.. But we don't have the testing capacity to do that at this time.
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk