Release Manager's Checklist
CVS Branch for release
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.
- After discussion on the main list, post the release schedule.
- Verify the root/index.htm, root/boost/version.hpp, and
release numbers are correct and agree.
- Verify via firstname.lastname@example.org
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:
- 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.
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.
- Pre-release activities complete enough to justify branch-for-release?
- Everybody happy?
- Branch for release:
- Tag the main trunk
- Branch the main trunk with the tag
- Post notice on main list. Remind developers that fixes which apply
to both Main Trunk and Branch have to be committed separately to both.
- 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".
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:
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
(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.
- General ZIP and TAR.GZ files
n_n_n is 1_28_0 or whatever
boost_zip 1_21_2 (creates zip.log)
gunzip -c boost_1_21_2.tar.gz | bzip2 > boost_1_21_2.tar.bz2
- 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
- Stop keep_isdn_awake
- Complete the SourceForge
- Admin | Edit Packages: 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 using WS_FTP Pro (126.96.36.199).
- Start keep_isdn_awake
- Local system: c:\boost\boost_n.n.n
- Tools | Synchronize | Control file name:
- boost_people (use "Test script only" first to verify all is working.)
- Connection: boost
- Update the root director (drag and drop files and directories) [Do the root directory last! This requested by users who happened to
connect during site updates.]
- Top level directory seems to copy files unnecessarily. Doesn't happened in
when whole sub-dir is drag and dropped.
At end of a file transfer, it is not unusual for there to be a 30-45 second
hang. This is not a sign of failure.
- Inspect index, etc dates
- 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,
- 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, and
root/Jamrules for the
next release and commit to CVS so developers have a place to add "Latest news"
- Delete obsolete files from yahoogroups files section.
26 November, 2003
© Copyright Beman Dawes 2001
Use, modification, and distribution are subject to the Boost Software License,
Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at