Release Manager's Checklist

This is being rewritten to the current Boost release precess.

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

• Pre-release activities all complete?

• Post notice to make sure all developers ready.

• Tag: Version_x_yy_z. If prior release failed, select "overwrite existing tags with the same name".

Distribution

• Upload files for SourceForge release incoming directory using WS_FTP Pro
  • Start keep_isdn_awake
  • Connection: SourceForge Release Upload | connect
  • Select Local system: c:\boost
  • Select Remote system: /incoming
  • Drag-and-drop the three release files from Local system to Remote system
  • Disconnect
  • Stop keep_isdn_awake

• Complete the SourceForge release procedure.
  • Admin | File Releases | Add Release for package name boost
  • New release name: 1.21.2 | create this release
  • Step 1: paste in release notes (in HTML). Be sure to note difference between .zip and .gz/bz2 files. Submit/Refresh
  • Step 2: Check appropriate files. Add Files and/or Refresh View
  • Step 3: For each file, select Processor and File Type, Update/Refresh
  • Setp 4: Email Release Notice: I'm sure. Send Notice.
  • Wait up to 30 minutes.
  • Check SourceForge release page and release notes with web browser.

• Consider putting up a temporary "Update in progress" root/index.html during site update

• 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)