Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-10-25 12:47:41

> "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 ;-)

Yes, of course, but there are always limits to the test. There are
a couple of libraries in 1.29 that are broken because there where mistakes
related to check-ins that somehow weren't detected in the tests. In addition,
each boost developer has some set of compilers that they can test
against. Thus when something gets checked-in it has the potential
to break other compilers that they don't test against. This might
not be the developer's fault, but just the usual portability
issues. So, I at least, have to depend on the running of regression
tests by others to be sure that I haven't broken things for compilers
and platforms I don't use.
> > 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
> testing.

Again, testing is always limited. My point is that it is very easy
to forget to check-in a change that is in a different part of the
tree (eg: in config) and break the build despite testing locally.
> 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.

Right I agree that this makes sense. We should only select the
critical fixes from the main that we want to put in 1.29.1 and
merge them out to a branch for that purpose.
> > 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.

So during the 1.29 release I made and tested a fix. I checked
it in on the main branch. I was considering moving it into 1.29,
but I didn't because all the regression tests Beman and other were
running were against the release candidate. The nature of the change
was such that I was uncomfortable putting it in the release candidate
until I was sure that it would work with more compilers than the ones
I test with.

So I think we are in agreement that the current release procedure
could be improved....


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