Re: [boost] Merge procedure to master (was: Release sponsorship (was: Re: Boost 1.58 schedule available?))

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 
branches.

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 
first.