Version 18 (modified by 14 years ago) ( diff ) | ,
---|
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.
- Update ReleaseSchedule
- Post the "Open for merges" heads up message. See Heads up messages to notify developers as deadlines loom
- 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 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 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.
Beta Release
Follow the tagging and release procedures below as for regular releases.
Between Beta and Release
See ReleasePractices/PostBetaMerges
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.
- Create SVN release tag:
- Copy (Branch/Tag)
- From WC at URL: https://svn.boost.org/svn/boost/branches/release
- To URL: https://svn.boost.org/svn/boost/tags/release/Boost_#_##_#[_RC#|_beta#].
- Create copy in the repository from: Head revision in the repository
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!
- See http://alexandria.wiki.sourceforge.net/File+Release+System+-+Offering+Files+for+Download for SourceForge File Release System documentation.
- 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 http://www.boost.org/LICENSE_1_0.txt)