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.