wiki:ReleasePractices/ManagerCheckList

Version 71 (modified by Daniel James, 11 years ago) ( diff )

--

  1. Release Manager's Checklist
    1. Introduction
    2. Release cycle initialization
    3. Monitoring Release Progress
    4. New Library Checklist
    5. Beta Release
    6. Between Beta and Release
    7. Build Distribution Packages
    8. Releases
    9. Subversion Beta and Release Tags

Release Manager's Checklist

Introduction

Release cycle initialization

  • In trunk, change version number in:
    • trunk/index.html (2 places; H2 and Release History link)
    • trunk/Jamroot (1 place)
    • trunk/boost/version.hpp (2 places) - Note that BOOST_LIB_VERSION should not include the patch version if it's zero.
    • trunk/more/getting_started/detail/release-variables.rst (4 places)

  • In trunk,
    • In more/getting_started, run bjam.
    • Inspect results.
  • Commit version number and Getting Started doc changes:
    • Commit trunk.
    • Merge to branches/release using merge_release_cycle_init.bat.
    • Commit to branches/release.

  • Verify the root/index.html, root/boost/version.hpp, root/Jamroot 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/live/feed/history/, for example for boost 1.39.0: 
    svn co https://svn.boost.org/svn/boost/website/public_html/live live-website
svn cp live-website/feed/templates/boost_x_xx_x.qbk live-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 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/libs/libraries.htm entry is OK, both in the alphabetic list and in the category lists.
  • root/libs/maintainers.txt entry is OK.
  • 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.
  • 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.

Before the beta test, the release managers should ensure that:

Beta Release

If it hasn't been done recently, run, then check and commit: 

cd %BOOST_RELEASE%
cd tools/regression
2release tools/regression [--dry-run]
cd tools/release
2release tools/release [--dry-run]

Follow the Build Distribution packages, Releases, and Subversion Beta and Release Tags procedures below as for regular releases.

This is probably a good time to pester people about updating website/public_html/beta/feed/history/boost_n_nn_0.qbk

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. 
    cd <boost-root>
bootstrap
.\bjam >bjam.log 2>&1
  • 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!

  • Create a directory on SourceForge:
    • login
    • Files
    • Click on "boost" folder to list current sub-directories | Add folder | Folder name: 1.46.0.beta.1 | Create
  • Upload release packages:
    • Click on folder just added.
    • Add File. Repeat for each distro file. Although the interface allows selecting multiple files, error recovery is much easier if files are uploaded one-by-one. For each file in the snapshot directory to be uploaded, select the file and hit "Upload". NOTE WELL: Spurious timeout error messages may appear. Ignore them. The MD5 checksum verification trumps error messages.
    • Add README file from trunk/tools/release/README
  • Verify MD5 checksums:
    • Use file "info" to get MD5 checksums; put them in a file, n.nn.n.md5, in the snapshot directory. It should look like this: 
      da33b65571cbbbd9c667dc6458e16a86 *boost_1_46_1.zip
b0a8949a3cd452c1bcb6cea8380cc01d *boost_1_46_1.7z
7375679575f4c8db605d426fc721d506 *boost_1_46_1.tar.bz2
341e5d993b19d099bf1a548495ea91ec *boost_1_46_1.tar.gz
    • Run: chg n.nn.n.md5 "\r" "" strip "\r" or md5sum can't find files
    • Run: md5sum -c -w <n.nn.n.md5 should list all files, status OK
  • Complete SourceForge release process:
    • login
    • Project Admin | File Manager
    • Verify files are present and in the correct directory.
    • Click Files (on upper menu bar), and check "Newest Files" entries are correct. (There may be a delay before labels appear)
  • 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 Beta and Release Tags

With TortoiseSVN:

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

Copyright Beman Dawes 2001, 2008

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

Note: See TracWiki for help on using the wiki.