Re: [boost] Change to Release Procedure? (was: Another reminder tomerge changes from the release branch)

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] * http://www.boost-consulting.com