Re: [boost] [git] Update submodules in boost.git

Subject: Re: [boost] [git] Update submodules in boost.git
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-12-05 09:30:06

On Thu, Dec 5, 2013 at 6:17 PM, Edward Diener <eldiener_at_[hidden]> wrote:
> On 12/5/2013 8:35 AM, Mateusz Loskot wrote:
>>
>> On 5 December 2013 13:13, Peter Dimov <lists_at_[hidden]> wrote:
>>>
>>> Tim Blechmann wrote:
>>>>
>>>>
>>>> this means that no library can depend of features of another library,
>>>> which is not part of the stable release or am i missing something?
>>>
>>>
>>>
>>> Yes. X/develop can't depend on Y/develop, only on Y/master.
>>
>> ----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> IMHO, that should be displayed in the guidelines in bold.
>
>
> If library X depends on library Y and needs some feature/fix of library Y in
> order to correctly implement some feature/fix of library X it seems to me
> that library X/develop can rely on library Y/develop, at least for
> individual testing of library X. Holding off the feature/fix of library X
> until Y/develop becomes Y/master seems a PITA to me.
>
> I know for my individual testing if my library X/develop needs something
> from library Y/develop I pull from library Y/develop in order to test.
>
> In this scenario library X needs to wait for library Y/develop to go to
> library Y/master before it goes to library X/master.

I might add that testing X/develop with Y/master has another drawback.
When a change is made to Y/develop, it is tested against
everything/master. It passes the tests but the change actually breaks
X. When the change is merged to Y/master, X is broken and it stays
that way until Y cycles again. If this happens during Boost release
preparation, these late failures can delay the release significantly.

I can see the upsides of this scheme too, but I don't think it should
be the only testing scheme. I'd prefer to have everything/develop test
results as well.