wiki:ReleasePractices/ManagerCheckList

Version 16 (modified by Beman Dawes, 14 years ago) ( diff )

Refine Getting Started version change-over

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

  • Request that the new version number is added to Trac.
  • In trunk, change version number in:
    • trunk/index.html
    • trunk/boost/version.hpp
    • trunk/Jamroot
    • trunk/more/getting_started/detail/release-variables.rst

  • 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 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.
    • Add to component list on Trac (this could possibly be done when the library is accepted, or even added to the review queue).

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

  • Do a local working copy Update to verify no past-deadline changes were made (and thus escaped testing).
  • Do a last review of the regression test results to verify no unexpected failures occurred.
  • Check developer's list to verify no last minute showstoppers were reported.

Build Distribution packages

  • If it hasn't already been done, run a snapshot using tools/release/snapshot.sh.

  • Build the distribution packages using tools/release/build_release_packages.sh.
  • Upload distribution packages to snapshot ftp site.
  • Important: Request final review from release team, developers list.

Distribution

  • Important: Release team must have signed off on packages. Ignoring this in the past has led to mistakes!

  • Upload release packages. WebDAV works well; use URL https://frs.sourceforge.net/b/be/beman_dawes/uploads/. The user id and password may have to be entered twice. Once the uploads directory window opens, use Windows Explorer as a drag-and-drop target. Note: Hit F5 to see the correct file sizes after upload.
  • Create or edit a release. Admin | File Releases: Click "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.

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.

  • 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


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)

Note: See TracWiki for help on using the wiki.