[boost] Re: ATTN: Merging changes to the release branch

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2004-10-30 02:38:07

David Abrahams wrote:
> Markus Schöpflin <markus.schoepflin_at_[hidden]> writes:
> 
>> Aleksey Gurtovoy wrote:
>> 
>>> Can I gently ask everybody to be more careful with integration of
>>>  changes from the main trunk to the release branch? If you have 
>>> to do it, please double-check everything (in particular, run the 
>>> diffs) before committing the merged files. We've already got the 
>>> new "boost/index.html" contents with *1.33.0* section stub in the
>>>  release branch, and dealing with more of something like this is 
>>> not going to help the release.
>> 
>> I'm wondering why the procedure isn't the other way round, eg. 
>> first check in on the release branch and then merge the fix onto 
>> the main branch if it affects the main branch as well.
> 
> We used to do it that way.  People would check things in on the RC 
> branch without enough testing.  At least if you check into the main 
> trunk first, you can find out if tests break before you merge into 
> the RC.

But running the tests on the main branch doesn't tell you a thing about
the results of the tests in the RC branch. So how are you supposed to
find out that a change would break the RC branch? Besides, there are 
currently only regression tests run for the RC branch and not the main 
branch, AFAICT.

> Keeping the RC clean is a higher priority than keeping the trunk
> clean.

That's exactly why I was proposing that the changes should go the other 
way round, not from main to RC but from RC to main as the danger is 
quite high that you merge something to RC that you didn't want to merge.

Markus