Subject: Re: [boost] Merge procedure to master (was: Release sponsorship (was: Re: Boost 1.58 schedule available?))
From: Peter Dimov (lists_at_[hidden])
Date: 2015-01-23 13:30:44
Barend Gehrels wrote:
> This is why I prefer to merge only once per release.
While I don't disagree with your list, I have to point out that, in case of
interdependent libraries, if everyone followed your lead and never merged to
master, you wouldn't be able to test your changes against their master as
you wouldn't know what it would be.
Or, to be clearer:
> Then you have to build and unit-test your to-be-merged code (on develop)
> where all other libraries are master-branch: it might break because of
> changes in other libraries.
If the other libraries do not keep their master branches up to date, you
will have no way to test your to-be-merged code against their master
So, in practice, if everyone merged once before release, at the same time,
we'd be having the usual chaos where nothing works and the release managers
need a month to figure out why.
While a merge to master can be painful in that interdependencies can cause
unexpected failures, it is still - arguably - better to learn about these as
soon as possible and fix them gradually over the course of normal
operations, instead of during one protracted pre-release march.
Which is why I merge to master sooner rather than later. Of course, there is
no single optimal strategy. For core libraries, specifically, on the one
hand, you can break the world if your master doesn't work, on the other,
nobody else can merge to master if they depend on your changes being merged
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk