|
Boost : |
From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-22 11:36:43
----- 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.
-Dave
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk