wiki:ReleasePractices/ManagerCheckList

Version 58 (modified by Daniel James, 12 years ago) ( diff )

There isn't a root/Jamfile.v2 any more.

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

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

  • Verify the root/index.htm, 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/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 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

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

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