Boost logo

Boost :

Subject: Re: [boost] Git: maintaining super-project
From: Daniel James (daniel_at_[hidden])
Date: 2013-12-04 06:13:00


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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk