From 117f43288c863aef476e6ea12c34da51e44380b9 Mon Sep 17 00:00:00 2001 From: Beman Dawes Date: Thu, 6 Mar 2003 18:04:22 +0000 Subject: [PATCH] now fixes suggested be merged from trunk to branch [SVN r17747] --- release_procedures.htm | 113 +++++++++++++++-------------------------- 1 file changed, 41 insertions(+), 72 deletions(-) diff --git a/release_procedures.htm b/release_procedures.htm index 13805b6..42d1a65 100644 --- a/release_procedures.htm +++ b/release_procedures.htm @@ -40,12 +40,12 @@ logs, and committing fixes to CVS.

  • Discussion on the main Boost mailing list to determine the target date for release candidate branch and tag of the CVS main trunk.
     
    • -
  • Release manager performs release candidate branch and tag.
    +
  • Release manager performs release candidate branch, and also tags the + branch point in main trunk.
     
    • -
  • Regression tests run on release candidate.
    +
  • Regression tests run on release candidate branch.
     
    • -
  • Developers commit fixes to the release candidate branch (and possibly - merge into the main trunk - see below).
    +
  • Developers fix problems, test, and commit fixes. See below for details.
     
  • Repeat previous two steps until release manager is satisfied.
     
    • @@ -71,98 +71,67 @@ logs, and committing fixes to CVS.

    Modified files committed to CVS on the main trunk will not be included in the release unless the developer explicitly commits the changes to the release candidate branch.
      -
  • To make a fix to the release candidate, the change must be committed to - the release candidate branch rather than the main trunk.  Here is a - typical procedure (assuming the release candidate branch is named RC_1_26_2):
    • +
  • If specific to the release candidate only, the fixes should be committed + directly to the release candidate branch. In the more common case of fixes + which apply to both the main trunk and the release branch, the fixes are best + made to the main trunk, and then merged into the release candidate branch.
    +
    + After a fix has been committed to the main trunk, here is a + typical procedure (assuming the release candidate branch is named RC_1_26_2) + to merge the fixed main trunk into the release candidate branch:
    • - 
    cvs update -r RC_1_26_2 [switch to the branch]
-[modify buggycode.hpp]
-cvs commit buggycode.hpp
-[repeat modify/commit as desired]
+    
    [After fixed code is committed to main branch]
+cvs update -r RC_1_26_2 [switch to the release candidate branch]
+cvs update -j HEAD buggycode.hpp [merge changes from the trunk to the branch]
+ --> RCS file: /cvsroot/boost/.../buggycode.hpp,v
+ -->    retrieving revision 1.4
+ -->    retrieving revision 1.6
+ -->    Merging differences between 1.4 and 1.6 into buggycode.hpp
 
-[when ready for first merge]
-cvs update -A [switch to the trunk]
-cvs update -j RC_1_26_2 buggycode.hpp [merge changes to the trunk]
-[resolve any conflicts, make sure it builds, etc. etc.]
-cvs commit -m "Merged from branch to trunk" buggycode.hpp
-cvs update -r RC_1_26_2 buggycode.hpp [switch back to the branch]
-cvs tag RC_1_26_2_last_merge buggycode.hpp [keep track of the last merge
-point]
-[merge is complete]
+cvs commit -m "Merged fix for problem xyz from trunk to branch" buggycode.hpp
 
-[modify buggycode.hpp]
-cvs commit buggycode.hpp
-[repeat modify/commit as desired]
-
-[when ready for second and subsequent merges]
-cvs update -A
-cvs update -j RC_1_26_2_last_merge -j RC_1_26_2 buggycode.hpp
-[resolve any conflicts, make sure it builds, etc. etc.]
-cvs commit -m "Second merge from branch to trunk" buggycode.hpp
-cvs update -r RC_1_26_2 buggycode.hpp
-cvs tag -F RC_1_26_2_last_merge buggycode.hpp [-F forces the tag to move; or
-create a new tag]
-[merge is complete]
-
    
+[Repeat as needed]
    -

    Switch to branch: Select file(s), then Modify | Update selection... | - Update settings | Sticky options | Retrieve rev/tag/branch: RC_1_26_2 | OK
    -
    - Edit files needing fixes.
    -
    - Commit changes: Modify | Commit... | Enter log message: ... | OK
    -
    - Switch back to main trunk: Modify | Update selection... | Update settings | - Reset any sticky date/tag/-k options. | OK
    -
    - If changes should also be merged into main trunk:

    +

    After fixed code is committed to main branch, switch to the release + candidate branch:

    -

    Merge changes from release candidate to main trunk: Modify | Update - selection... | Merge options | Only the rev/tag: RC_!_26_2 | OK
    -
    - Commit merge results: Modify | Commit... | Enter log message: ... | OK

    +

    Select file(s)

    +

    Modify | Update selection... | + Update settings | Sticky options | Retrieve rev/tag/branch: RC_1_26_2 | OK

    -

    Note that if a second or subsequent merge is required:

    +

    Merge changes from main trunk into the release candidate branch:

    -

    Switch to branch: Select file(s), then Modify | Update selection... | - Update settings | Sticky options | Retrieve rev/tag/branch: RC_1_26_2 | OK

    -

    Tag to keep track of last merge point: Modify | Create tag on - selection... | Enter tag name: RC_1_26_2_last_merge | Overwrite existing - tags with same name | OK

    -

    Edit files needing fixes.

    -

    Commit changes: Modify | Commit... | Enter log message: ... | OK

    -

    Switch back to main trunk: Modify | Update selection... | Update - settings | Reset any sticky date/tag/-k options. | OK
    -
    - If changes should also be merged into main trunk:

    -
    -

    Merge changes from release candidate to main trunk: Modify | Update - selection... | Merge options | [select] Plus with this rev/tag: - RC_1_26_2 | [and above that, without selecting, enter ]Only the rev/tag: - RC_1_26_2_last_merge | OK
    -
    - Commit merge results: Modify | Commit... | Enter log message: ... | OK

    -
    +

    Modify | Update selection... | + Update settings | Merge options | Only this rev/tag: HEAD | OK

    +
    +

    Commit merge results:

    +
    +

    Modify | Commit... | Enter log message: ... | OK

    Release Procedures for the Release Manager

    -

    (To be supplied)

    +

    At time of branch-for-release:

    +

    Acknowledgements

    This web page was written by Beman Dawes, with helpful suggestions from Dave -Abrahams and Steve Robbins. Jim Hyslop contributed the detailed CVS procedures.

    +Abrahams and Steve Robbins. Jim Hyslop contributed the original CVS procedures. +Updated by Jeff Garland after 1.29 release based on list discussions.

    Revised: -28 January, 2002

    +06 March, 2003