Re: [boost] Release procedures?

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-23 08:16:24

At 11:36 AM 1/22/2002, David Abrahams wrote:
 >
 >----- Original Message -----
 >From: "Beman Dawes" <bdawes_at_[hidden]>
 >
 >> If we do that, is there a way to do a commit that says "commit this
 >change
 >> to both the main trunk and the release candidate branch?
 >
 >No, but I can make you an easy Python script to do it.
 >
 >> If not, who is responsible for merging fixes back into the main trunk?
 >
 >Individual developers. They will be motivated to do it; remember they're
 >going to get mail if they leave bugs in the code. Anyway, these changes
 >will
 >be few. If they need to go back and find the fix, they can just do a 
merge
 >with the last release.
 >
 >After the release, someone (anyone) can do:
 >
 >    cvs update -AdP
 >    cvs -n update -dP -jVersion_<last-release>
 >
 >Note the files that would be merged, and notify the group or appropriate
 >authors. Again, this should be relatively few files.
 >
 >> Or merging changes from the main trunk into the release branch?
 >
 >That shouldn't happen, really. When you get notice of a bug in the 
release
 >candidate, you go back to that branch and fix the bug. Then if you want 
it
 >in the main trunk immediately you can:
 >    cvs update -j<release-branch-tag> filenames...
 >
 >> How do other
 >> people typically ensure that the merge actually gets done?  Without
 >> becoming a time waster or administrative nightmare?
 >
 >I don't think there's anything to fear with this model.

Well, let's give it a try for a release or two.

I'll update the procedure doc accordingly.

What would be a help is if you would figure out the command line cvs 
procedure for the following scenario:

Developer's working copy contains the (possibly slightly out-of-date with 
respect to the repository) main trunk with some new work-in-progress 
changes made to unrelated files.  Developer wants to fix a bug in a release 
candidate file.  What is the procedure so that at completion:

* Both the repository main trunk and release candidate branch have the bug 
fix applied.

* The developer's working copy is set back to the main trunk again, and his 
or her work-in-progress is still present as are the bug fixes.

I'll work out and test the same procedure for a WinCVS developer.

--Beman