Peter Dimov schreef op 23-1-2015 om 19:30:
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.
Thanks for the addition. I see the problem. From Boost.Geometry perspective we're on the dependant side, and that might be reflected in my list indeed. However, if we merge blindly, ignoring errors, for example once per week, that would feel really uncomfortable to me, and would it really help? Barend