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 also tags the branch point in main trunk.
Regression tests run on release candidate branch.
Developers fix problems, test, and commit fixes. See below for details.
Repeat previous two steps until release manager is satisfied.
Release manager rolls out the actual release.

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

Command Line CVS:
[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

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

[Repeat as needed]
WinCVS:

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

Select file(s)

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

Merge changes from main trunk into the release candidate branch:

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

At time of branch-for-release:

Tag the main trunk merged_to_RC_n_n_n.
Branch the main trunk with the tag RC_n_n_n.

This web page was written by Beman Dawes, with helpful suggestions from Dave Abrahams and Steve Robbins. Jim Hyslop contributed the original CVS procedures. Updated by Jeff Garland after 1.29 release based on list discussions.

Revised: 06 March, 2003