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

Subject: Re: [boost] [git] Update submodules in boost.git
From: Peter Dimov (lists_at_[hidden])
Date: 2013-12-08 15:09:10

Andrey Semashev wrote:
> Later in the discussion Peter assured me that the release managers' job 
> would be to
manually select which commits to master are problematic ones and exclude 
them from the Boost release. This sounds like a tedious task to me, but it 
would remove the delay in the Boost release at least.

It's not necessarily tedious because manual intervention would only be 
required in the cases in which there is a conflict.

In this approach, the develop branch of the superproject will be scripted to 
always point to the tip of the master branches of the library repositories, 
whereas, per gitflow, the master branch of the superproject will point to 
the latest release. A new release would be done on a release branch (again, 
per gitflow) which initially starts from boostorg:develop and, if there are 
no issues, gets merged into boostorg:master. Reverting boostorg:develop 
commits on the release branch will only be needed in the rare cases in which 
a library needs to be rolled back. (It's also possible for boostorg to have 
a scripted branch, say "latest", which points to "develop" in all libraries, 
but it would play no role for the releases.)

This is, of course, not the only option. It's just one way of doing things.

> But still it doesn't help individual developers since their tests would be 
> broken for longer times and integration problems not detected early.

As I said, it's a tradeoff. If your library depends on many other libraries, 
some of which tend to often be broken on their develop branch, you would 
prefer to test your library against their master branches, since these would 
hopefully be less broken. This allows you to proceed with your own tests 
without waiting for the dependencies to clean up their acts.