Boost Release Procedures

Introduction
Procedure Overview
Procedures for Developers
Procedures for the Release Manager
Acknowledgements

Introduction

Each release of Boost software is overseen by a release manager, who coordinates release activities via the Boost mailing list, as well as performing the detailed procedures for the release.

Boost developers assist the release manager by reviewing regression test logs, and committing fixes to CVS.

Release Procedure Overview

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.
Regression tests run on the release candidate branch.
Developers develop, test, and commit fixes to the main branch.
Fixes are then merged out to the release candidate branch.
Repeat previous three steps until release manager is satisfied.
Release manager rolls out the actual release.

Note that in some exceedingly rare cases the developer may need to create the fix directly on the candidate branch. This would occur if the main branch has divreged significantly from the release candidate branch or the regression test of the main branch is broken preventing testing of fixes. If you are unsure ask for help by posting on the developer list.

Release Procedures for Developers

As the release candidate branch date approaches (as announced on the main mailing list), bring the main trunk CVS files you are responsible for into a stable state.
If you know of changes in either your code or its dependencies, start checking regression test results to ensure your tests still pass. Don't necessarily wait for the initial release tagging.
After the release manager announces that the release candidate branch has occurred, check the latest regression test results to be sure your tests haven't broken.
Developers can continue working on main trunk code changes after the release candidate branch has occurred. There is no need to wait until the release itself. 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):

Command Line CVS:
[After fix code is committed to main branch]
cvs update -r RC_1_26_2 [switch to the 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

cvs commit -m "Merged fix for problem xyz from trunk to branch" buggycode.hpp

[Repeat as needed]
WinCVS:

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:

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

Note that if a second or subsequent merge is required:

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

Release Procedures for the Release Manager

(To be supplied)

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. Updated by Jeff Garland after 1.29 release based on list discussions.

Revised: 28 January, 2002