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

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

Jeff