wiki:ReleasePractices/ManagerCheckList

Version 40 (modified by Beman Dawes, 13 years ago) ( diff )

Update release msg text

  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 Release Tag

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/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 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 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/index.html includes the library in it's list of new libraries.
  • root/libs/libraries.htm entry is OK, both in the alphabetic list and in the category lists.
  • root/libs/maintainers.txt entry is OK.
  • website/public_html/beta/feed/history/ entry is OK.
  • The library has been added to the website documentation list
  • The library's root/libs/xxx directory contains an index.htm or 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.
  • Component has been added to Trac. See ​https://svn.boost.org/trac/boost/admin/ticket/components
  • 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.

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

  • Upload release packages. 
    cd <snapshot-directory>
dir boost_*              // verify this gets only the desired files
rsync -avP -e ssh boost_* beman_dawes@frs.sourceforge.net:uploads/
  • Create or edit a release. Project Admin | Feature Settings | File Release System | Manage | "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. Be sure to download a file with the appropriate line endings for your platform.

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.

  • 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): 
    Start VirtualBox/Ubuntu, then:
./mount-d.sh
cd d:/boost-release-snapshot
#scp -r boost_1_39_0.zip grafik@beta.boost.org:/u/grafik/www.boost.org/archives/live
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 and recapping "Latest News". 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.