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

Historically, items on this checklist were accomplished by scripts written in Perl, Python, Bash, C++, and as Windows command files, or by point-and-click on a FrontPage or other GUI based program. Long term the plan is to move as much as possible of these to C++, as the one language all Boost developers are comfortable with.

Pre-release activities

• After discussion on the main list, post the release schedule.

• 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 each new library added this release:
  • Verify website/public_html/beta/feed/history/ entry has been made and reads well.
  • Verify root/libs/libraries.htm entry has been made, both in the alphabetic list and in the category lists.
  • Verify root/libs/maintainers.txt entry has been made.
  • Verify library has been added to the website documentation list
  • Verify the root/libs/xxx directory contains an index.htm or index.html file; either the main docs or a redirection to the main docs. To do: automate this.
  • Skim read the primary docs pages to make sure they meet Boost requirements and guidelines. Don't leave this until too late; it has turned up lots of issues in the past.
  • Generate the header dependency table and update the CVS. To do: coordinate with John Maddock's new dependency tools.

• 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 the SourceForge bug tracker, to verify that all posted bug reports are being investigated, fixed, rejected, or otherwise dealt with.

• Monitor CVS 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.

Subversion Release Tag

• Do a local working copy Update to verify no past-deadline changes were made (and thus escaped testing).

• Do a last review of the regression test results to verify no unexpected failures occurred.

• Check developer's list to verify no last minute showstoppers were reported.

• Create SVN release tag:
  • Copy (Branch/Tag)
  • From WC at URL: ​https://svn.boost.org/svn/boost/branches/release
  • To URL: ​https://svn.boost.org/svn/boost/tags/release/Boost_#_##_#[_RC#|_beta#].
  • Create copy in the repository from: Head revision in the repository

Build Distribution packages

• Build the distribution packages using tools/release/???.sh.

• Upload distribution packages to snapshot ftp site.

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

Distribution

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

• See ​http://alexandria.wiki.sourceforge.net/File+Release+System+-+Offering+Files+for+Download for SourceForge File Release System documentation.

• Upload release packages. WebDAV works well; use URL ​https://frs.sourceforge.net/b/be/beman_dawes/uploads/. The user id and password may have to be entered twice. Once the uploads directory window opens, use Windows Explorer as a drag-and-drop target. Note: Hit F5 to see the correct file sizes after upload.

• Create or edit a release. Admin | File Releases: Click "Add Release" for Package Name "boost".

• Step 1: New release name: 1.37.2 [beta] | create this release
• Step 2: paste in release notes (in HTML). Submit/Refresh

Boost source files with types .bz2 and .gz are created with POSIX-style (\n) line endings. Source files with types .7z and .zip are created with Windows-style (\r\n) line endings. The content is otherwise identical.

If you are new to Boost, be sure to read the Getting Started Guide. See www.boost.org

• Step 3: Check appropriate files. Add Files and/or Refresh View
• Step 4: For each file, select Processor "Platform-Independent" and File Type, Update/Refresh
• Step 5: Email Release Notice: Check "I'm sure", click "Send Notice"

• Wait a bit. The docs say 30 minutes, but that seems to have been reduced to less than 5 minutes.
• Check SourceForge release page and release notes with web browser.

• Update the web site: TBS

• 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 and recapping "Latest News". Post as separate messages to: boost, boost-announce, boost-users, comp.lang.c++.moderated, c++std-news

• Ready trunk/index.html, trunk/boost/version.hpp, and trunk/Jamroot, trunk/more/getting_started/detail/release-variables.rst for the next release and commit to Subversion. (Possibly also update trunk/more/getting_started/unix-variants.rst, and also work rebuilding the getting started guide into the process somewhere).

• Merge version number changes to branches/release.

---

Copyright Beman Dawes 2001, 2008

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