Release Manager's Checklist

This is a placeholder page in that the content needs to be rewritten to account for the new process. When that happens the page can move to the new web site.

Introduction

Historically, items on this checklist were accomplished by scripts written in Perl, Python, Bash, C++, and as Windows command files, or by point-and-click on a FrontPage or other GUI based program. Long term the plan is to move as much as possible of these to C++, as the one language all Boost developers are comfortable with.

Pre-release activities

• After discussion on the main list, post the release schedule.

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

• Remove the oldest "Latest News" from root/index.htm.

• For each new library added this release:

• Verify root/index.htm Latest News 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 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.

• Monitor ​http://boost.sourceforge.net/regression-logs/inspection_report.html to verify problems are actively being reduced. Make sure none of the problems are in files the release manager is responsible for.

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

CVS Branch for release

• Pre-release activities complete enough to justify branch-for-release?

• Everybody happy?

• Branch for release:
  • Tag the main trunk merged_to_RC_n_n_n.
  • Branch the main trunk with the tag RC_n_n_n.

• Post notice on main list. Remind developers that fixes which apply to both Main Trunk and Branch have to be committed separately to both.

CVS Release

• Pre-release activities all complete?

• Post notice to make sure all developers ready.

• Tag: WinCVS: Select site, then tag (Modify|Create tag..., toolbar T on doc). New tag name: Version_1_21_2 (or whatever). If prior release failed, select "overwrite existing tags with the same name".

Distribution

These procedures are given for a particular release manager's machine. The plan is to replace them with more generic procedures over time.

• Create folders for export:

c:\boost\boost_1_28_0 c:\boost\temp\boost_1_28_0

Note that several batch files assume these locations and naming schemes.

• Export Win32 distribution: WinCVS | Remote | Checkout Module

Checkout settings: module name and path on the server: boost, local folder to checkout to: c:\boost\boost_1_28_0 [for 1.29.0 export, put everything in a boost_1_29_0/boost subdirectory. Experiments with 1.30.0 tried boost/boost as the path on server, but that just resulted in getting the boost header subdirectory only.]

Checkout options: (check) By revision/tab/branch: Version_1_28_0, (check) Do not create CVS directories (export)

This results in the follow command: cvs -z9 export -r Version_1_28_0 boost (in directory C:\boost\boost_1_28_0)

(takes about ten minutes)

(rename boost-root if needed !!!!!!!!!!!!!!!!!!!)

• Export Unix distribution: similar to above, except target is c:\boost\temp\boost_1_28_0 and set global for UNIX nl.

• !!!!!! VERY IMPORTANT: WinCVS | Set Preferences | Global back to non-UNIX nl. !!!!!!!!!!!!!!!

• Add regression results web pages into package (new in 1.33 so this is just a shot at the process - jeff) download all the regression results from website (may need meta-comm help on this) unpack the regression results into tools/regression/latest_release

• General ZIP and TAR.GZ files

n_n_n is 1_28_0 or whatever

cd \boost boost_zip 1_21_2 (creates zip.log) boost_tar_gz 1_21_2 bash

gunzip -c boost_1_21_2.tar.gz | bzip2 > boost_1_21_2.tar.bz2 exit

• Upload and unpack the .zip release candidate to a SourceForge web services sub-directory. Post a message to the main list asking developers to check contents. (Daniel Frey has volunteered to help check).

• Upload files for SourceForge release incoming directory using WS_FTP Pro
  • Start keep_isdn_awake
  • Connection: SourceForge Release Upload | connect
  • Select Local system: c:\boost
  • Select Remote system: /incoming
  • Drag-and-drop the three release files from Local system to Remote system
  • Disconnect
  • Stop keep_isdn_awake

• Complete the SourceForge release procedure.
  • Admin | File Releases | Add Release for package name boost
  • New release name: 1.21.2 | create this release
  • Step 1: paste in release notes (in HTML). Be sure to note difference between .zip and .gz/bz2 files. Submit/Refresh
  • Step 2: Check appropriate files. Add Files and/or Refresh View
  • Step 3: For each file, select Processor and File Type, Update/Refresh
  • Setp 4: Email Release Notice: I'm sure. Send Notice.
  • Wait up to 30 minutes.
  • Check SourceForge release page and release notes with web browser.

• Consider putting up a temporary "Update in progress" root/index.html during site update

• Update the web site:

cd ...\boost_1_28_0 tar -cf site.tar * bzip2 -k site.tar

dir site.tar.bz2 pscp site.tar.bz2 beman_dawes@…:/home/groups/b/bo/boost/htdocs/

keep_idsn_awake in another window.

c:\bgd\util\putty\plink.exe beman_dawes@… cd /home/groups/b/bo/boost/htdocs pwd ls -l site.tar.bz2

rm -fr boost rm -fr doc rm -fr libs rm -fr more rm -fr people rm -fr status rm -fr tools bunzip2 -kc site.tar.bz2 | tar -x ls exit

stop keep_isdn_awake

• 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@…

• Using the SourceForge shell services (sf_shell_svc.bat), cd /home/groups/b/bo/boost/htdocs, and rename regression tests as necessary.

• Burn "Key Directories" CD for off-site backup.

• Make sure CVS working copy is updated to main branch!

• Ready root/index.htm, root/boost/version.hpp, root/Jamfile.v2 and root/Jamrules for the next release and commit to CVS so developers have a place to add "Latest news" blurbs.

• Delete obsolete files from yahoogroups files section.

Copyright Beman Dawes 2001

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)