Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-25 10:43:15

"Jeff Garland" <jeff_at_[hidden]> writes:

> > I think the whole approach of merging from the release to the main
> > trunk is totally misguided. If there's a fix which _can_ be applied in
> > the trunk, it should be made there *first*.
> This works fine as long as the we are sure that the fix
> doesn't depend on some other change that isn't in the
> release candidate.

My assumption is that such fixes would be tested at least once before
being checked into the trunk ;-)

> For most changes I would expect that this would be true. If,
> however, there was a change in the config stuff then someone could
> break the release candidate by checking in a change without the
> dependent config changes.

Yes, it's always easy to break things if you do a checkin without

> Also, if the trunk is broken or no regression tests are being run on
> the trunk it will be hard to validate that the change to the trunk
> is safe and therefore know that it is safe to merge into the release
> candidate.

Huh? Anyone can run regressions on the trunk. I admit that if the
trunk is broken in some fundamental way [e.g. type_traits ;-)] it
might make testing difficult, but we try not to leave things that way
for long. If it means that we have to wait a little while before
putting changes into the release candidate, that's probably a good

Also, consider what's going to happen if we have a 1.29.1 release:
changes that are currently in the trunk will be moved to the candidate
branch. This seems like the normal way things will work.

> Anyway, no matter which direction the merge is done, in most
> cases I think the normal procedure should be to merge right
> away for low risk changes (eg: documentation). For code
> changes which carry higher risk it would be nice to have a
> regression test done on the changed branch before the merge
> is done.

Well, of course, you test before you check in.

                    David Abrahams
dave_at_[hidden] *

Boost list run by bdawes at, gregod at, cpdaniel at, john at