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
> Keeping the RC clean is a higher priority than keeping the trunk
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk