Release Manager's Checklist

This page is gradually being rewritten to reflect the current Boost release process. Until the rewrite is complete, some sections are out-of-date

Introduction

Release cycle initialization

• Update Trac milestones: ​https://svn.boost.org/trac/boost/admin/ticket/milestones

• In trunk, change version number in:
  • trunk/index.html (2 places; H1 and Release History link)
  • trunk/Jamroot (1 place)
  • trunk/boost/version.hpp (2 places)
  • trunk/more/getting_started/detail/release-variables.rst (3 places)

• In trunk,
  • In more/getting_started, run bjam.
  • Inspect results.

• Commit version number and Getting Started doc changes:
  • To trunk.
  • Merge and commit to branches/release.

• Update ReleaseSchedule

• Post the "Open for merges" heads up message. See Heads up messages to notify developers as deadlines loom

• Verify the root/index.htm, root/boost/version.hpp, root/Jamfile.v2 and root/Jamrules release numbers are correct and agree.

• Verify via jamboost@… that bjam pre-built executables up-to-date.

• Create a placeholder for release information at: website/public_html/beta/feed/history/, for example for boost 1.39.0:

  svn co https://svn.boost.org/svn/boost/website/public_html/beta beta-website
  svn cp beta-website/feed/templates/boost_x_xx_x.qbk beta-website/feed/history/boost_1_39_0.qbk
  

Then edit the version number (in two places) in the new entry and commit.

Monitoring Release Progress

• Monitor ​http://boost.sourceforge.net/regression-logs/inspection_report.html to verify problems are actively being reduced. Make sure none of the problems are in files the release manager is responsible for.

• Monitor regression tests (​http://boost.sourceforge.net/regression-logs) to verify that errors are actively being reduced or accounted for on key platforms and compilers.
  • Boost errors are being actively worked on by library maintainers.
  • Compiler or standard library errors are at least identified, and preferably reported to the supplier.
  • No errors remain uninvestigated or unclassified.

• Monitor the developer and user mailing lists to verify that all posted patches are being applied, rejected, or otherwise dealt with.

• Monitor the developer and user mailing lists, and outstanding tickets, to verify that all posted bug reports are being investigated, fixed, rejected, or otherwise dealt with.

• Monitor SVN commits to verify that all the expected and/or promised content actually gets committed. Try to get developers to avoid last minute commits of major changes.

New Library Checklist

Before a new library is merged into branches/release, the release manager should verify:

• root/index.html includes the library in its list of new libraries.
• root/libs/libraries.htm entry is OK, both in the alphabetic list and in the category lists.
• root/libs/maintainers.txt entry is OK.
• website/public_html/beta/feed/history/ entry is OK.
• The library has been added to the website documentation list
• The library's root/libs/xxx directory contains an index.html file with either the main docs or a redirection to the main docs.
• The primary docs pages meet Boost requirements and guidelines. Don't leave this until too late; it has turned up lots of issues in the past.
• Component has been added to Trac. See ​https://svn.boost.org/trac/boost/admin/ticket/components
• Trunk inspection report is clean.
• Trunk regression tests are reasonably clean or marked up.

After a new library is merged into branches/release, the release manager should verify:

• Doc builds, if any, are running properly.
• Release branch inspection report is clean.
• Release branch regression tests are reasonably clean or marked up.

Beta Release

Follow the tagging and release procedures below as for regular releases.

Between Beta and Release

See ReleasePractices/PostBetaMerges

Build Distribution packages

• If it hasn't already been done, run a snapshot using tools/release/snapshot.bat.

• Build the distribution packages using tools/release/build_release_packages.bat.

  cd <snapshot-directory>
  %BOOST_TRUNK%\tools\release\build_release_packages boost_X_XX_X_beta1 >build_packages.log 2>&1
  

• Unpack .bz2 and .7z distribution packages on Linux and Windows, respectively, and verify bootstrap build works OK.

• Upload distribution packages to snapshot ftp site.

• Important: Request final review from release team, developers list.

Releases

• Important: Release team must have signed off on packages. Ignoring this in the past has led to mistakes!

• See ​http://sourceforge.net/apps/trac/sourceforge/wiki/Release%20files%20for%20download for SourceForge File Release System (RFS) documentation.

• Create a directory on SourceForge:
  • login
  • Develop | Project Admin | File Manager
  • Click on the "boost" folder's gear icon to bring up context menu | New folder | New folder name: 1.41.0.beta.1

• Upload release packages:

  cd <snapshot-directory>
  dir boost_*              // verify this gets only the desired files
  %BOOST_TRUNK%\tools\release\upload2sourceforge 1.41.0.beta.1
  

• Complete SourceForge release process:
  • login
  • Project Admin | File Manager
  • Verify files are present and in the correct directory.
  • Click each file to set properties:
    • Label: "Windows line endings" or "Unix line endings"
    • Do not set Platform, since we have no default download platform.
    • Save.
  • Click Files (on upper menu bar), and check "Newest Files" entries are correct. (There may be a delay before labels appear)

• Apply Subversion release tag. (See Subversion Release Tag)

• Upload boost_n_n_n.zip to the web server (Requires server keys/access; currently only Rene and Beman. Also assumes ~/.ssh has Beman's key files):

  cd <snapshot-directory>
  rsync -avP -e ssh boost_1_39_0.zip grafik@beta.boost.org:/u/grafik/www.boost.org/archives/live/
  

• Merge the website/beta to website/live. (Anyone with website svn write permission.)

• Check actual www.boost.org site with browser. Look at a bunch of files that should have been updated to make sure the updates actually "took".

• Post a message announcing the release. See sample release notice. Post as separate messages to: boost, boost-announce, boost-users, comp.lang.c++.moderated, c++std-news

Subversion Release Tag

With TortoiseSVN:

• In the snapshot-directory, see build_packages.log to get the revision number of the release.

• Do a log on an updated local working copy of branches/release.

• Select the revision number for the release; right-click and select "Create branch/tag from revision".
  • To URL: ​https://svn.boost.org/svn/boost/tags/release/Boost_n_nn_n_beta1
  • Specific revision in repository: should already be set to correct revision number.
  • Log message: Release n.n.n beta 1
  • Click OK

---

Copyright Beman Dawes 2001, 2008

Distributed under the Boost Software License, Version 1.0. (See http://www.boost.org/LICENSE_1_0.txt)