On 04.12.2013 15:13, Daniel James wrote:
On 4 December 2013 10:34, Vladimir Prus
wrote: On 04.12.2013 13:44, Daniel James wrote:
On 4 December 2013 09:40, Vladimir Prus
wrote: On 04.12.2013 13:13, Daniel James wrote:
On 4 December 2013 07:27, Cox, Michael
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