# Release Procedures

| Home | Libraries | People | FAQ | More

# 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 release candidate.
- Developers commit fixes to the release candidate branch (and possibly merge into the main trunk - see below).
- 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.
- 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:

> >     cvs update -r RC_1_26_2 [switch to the branch]
> >     [modify buggycode.hpp]
> >     cvs commit buggycode.hpp
> >     [repeat modify/commit as desired]

> >     [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]

> >     [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]

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

Revised: 28 January, 2002