Boost logo

Boost :

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

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

> > "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.

That's exactly why I want to see fixes in the trunk first, where more
people will be exercising the code.

> > > 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.

Sounds like a wise decision.

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

I hope we also agree on a specific way to improve it.
Do we?

                    David Abrahams
dave_at_[hidden] *

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