wiki:ReleasePractices/ManagerCheckList

Version 79 (modified by Marshall Clow, 10 years ago) ( diff )

Added svn branch command for non-TortoiseSVN users.

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, runb2.
    • 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.
  • Update the Google calendar as described in ReleaseSchedule so that it is always several releases ahead. This is really important; it causes endless trouble if the calendar isn't updated.

  • Verify the root/index.html, root/boost/version.hpp, root/Jamroot release numbers are correct and agree.

  • Verify via jamboost@… that b2 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

Verify branch and release index.html have been updated with the number of new libraries.

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 the distribution package for your local operating system, and verify build works OK. No point in posting a release candidate already known to fail!
    cd <boost-root>
    bootstrap
    .\b2 >build.log 2>&1
    
  • Upload distribution packages to snapshot ftp site.

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
      
    • Windows only: 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)
  • If this is a final release, rather than a beta release, let the webmaster (currently Daniel) know the release is ready to go live. Wait until the site is updated before posting the release message.

  • Post a message announcing the release.

Subversion Beta and Release Tags

Obtain the revision number from the end of build_packages.log

With TortoiseSVN:

  • Select the revision number for the release; right-click and select "Create branch/tag from revision".

With a command-line tool (where XXXXX is the revision that you want to branch from)

https://svn.boost.org/svn/boost/tags/release/Boost_n_nn_n_beta1 \ -m "Release n.n.n beta 1"


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.