Re: [boost] Git: maintaining super-project

Subject: Re: [boost] Git: maintaining super-project
From: Vladimir Prus (ghost_at_[hidden])
Date: 2013-12-04 06:16:33

On 04.12.2013 15:13, Daniel James wrote:
> On 4 December 2013 10:34, Vladimir Prus <ghost_at_[hidden]> wrote:
>> On 04.12.2013 13:44, Daniel James wrote:
>>>
>>> On 4 December 2013 09:40, Vladimir Prus <ghost_at_[hidden]> wrote:
>>>>
>>>> On 04.12.2013 13:13, Daniel James wrote:
>>>>>
>>>>>
>>>>> On 4 December 2013 07:27, Cox, Michael <mhcox_at_[hidden]>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> The following should get you what your asking for, if I understand you
>>>>>> correctly:
>>>>>>
>>>>>> git clone --recursive -b develop https://github.com/boostorg/boost
>>>>>>
>>>>>> git submodule foreach git checkout develop
>>>>>
>>>>>
>>>>>
>>>>> Most developers won't do this, they'll be using the master branch of
>>>>> the super project, and only checking out develop for the modules
>>>>> they're concerned with.
>>>>
>>>>
>>>>
>>>> And then any incompatibilities are discovered a week before release, I
>>>> suppose?
>>>
>>>
>>> Well, you should only be making bug fixes a week before release, and
>>> changes for an upcoming release shouldn't be made in the develop
>>> branch. The idea is to use the git flow process to manage changes.
>>
>>
>> The point is I change module X and you change module Y and these changes
>> collide, then having us test against previously-released version of Boost,
>> or some random-state-of-submodule-references, as opposed to master branches
>> of everything, will necessary mean the collision will be detected later in
>> release cycle.
>
> You'll be testing against the master branches of anything.

We're back to square one. Checking out master branch of the superproject will only
get you master branches of everything if:

- as soon as anybody commits anything to master branch of his library, he creates
   a pull request for super project

- this pull request is merged quickly

Do you expect both conditions will hold?

- Volodya