Version 70 (modified by 11 years ago) ( diff ) | ,
---|
Release Manager's Checklist
Introduction
Release cycle initialization
- Update Trac milestones: https://svn.boost.org/trac/boost/admin/ticket/milestones
- In trunk, change version number in:
- trunk/index.html (2 places; H2 and Release History link)
- trunk/Jamroot (1 place)
- trunk/boost/version.hpp (2 places) - Note that
BOOST_LIB_VERSION
should not include the patch version if it's zero. - trunk/more/getting_started/detail/release-variables.rst (4 places)
- In trunk,
- In more/getting_started, run bjam.
- Inspect results.
- Commit version number and Getting Started doc changes:
- Commit trunk.
- Merge to branches/release using merge_release_cycle_init.bat.
- 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.html, root/boost/version.hpp, root/Jamroot 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/live/feed/history/, for example for boost 1.39.0:
svn co https://svn.boost.org/svn/boost/website/public_html/live live-website svn cp live-website/feed/templates/boost_x_xx_x.qbk live-website/feed/history/boost_1_39_0.qbk }}} Then edit the version number (in two places) in the new entry and commit. == Monitoring Release Progress == * 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. == New Library Checklist == Before a new library is merged into branches/release, the release manager should verify: * root/libs/libraries.htm entry is OK, both in the alphabetic list and in the category lists. * root/libs/maintainers.txt entry is OK. * The library's root/libs/xxx directory contains an 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. * 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. Before the beta test, the release managers should ensure that: * root/index.html includes the library in its list of new libraries. * website/public_html/beta/feed/history/ entry is OK. * The library has been added to the website documentation list * Component has been added to Trac. See https://svn.boost.org/trac/boost/admin/ticket/components == Beta Release == If it hasn't been done recently, run, then check and commit: {{{ cd %BOOST_RELEASE% cd tools/regression 2release tools/regression [--dry-run] cd tools/release 2release tools/release [--dry-run] }}} Follow the '''Build Distribution packages''', '''Releases''', and '''Subversion Beta and Release Tags''' procedures below as for regular releases. This is probably a good time to pester people about updating website/public_html/beta/feed/history/boost_n_nn_0.qbk == 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 }}} * Unpack .bz2 and .7z distribution packages on Linux and Windows, respectively, and verify bootstrap build works OK. {{{ cd <boost-root> bootstrap .\bjam >bjam.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! * See http://sourceforge.net/apps/trac/sourceforge/wiki/Release%20files%20for%20download for SourceForge File Release System (RFS) documentation. * Create a directory on SourceForge: * login * Files * Click on "boost" folder to list current sub-directories | Add folder | Folder name: 1.46.0.beta.1 | Create * Upload release packages: * Click on folder just added. * Add File. Repeat for each distro file. Although the interface allows selecting multiple files, error recovery is much easier if files are uploaded one-by-one. For each file in the snapshot directory to be uploaded, select the file and hit "Upload". NOTE WELL: Spurious timeout error messages may appear. Ignore them. The MD5 checksum verification trumps error messages. * Add README file from trunk/tools/release/README * Verify MD5 checksums: * Use file "info" to get MD5 checksums; put them in a file, n.nn.n.md5, in the snapshot directory. It should look like this: {{{ da33b65571cbbbd9c667dc6458e16a86 *boost_1_46_1.zip b0a8949a3cd452c1bcb6cea8380cc01d *boost_1_46_1.7z 7375679575f4c8db605d426fc721d506 *boost_1_46_1.tar.bz2 341e5d993b19d099bf1a548495ea91ec *boost_1_46_1.tar.gz }}} * Run: chg n.nn.n.md5 "\r" "" // strip "\r" or md5sum can't find files * Run: md5sum -c -w <n.nn.n.md5 // should list all files, status OK * Complete SourceForge release process: * login * Project Admin | File Manager * Verify files are present and in the correct directory. * Click Files (on upper menu bar), and check "Newest Files" entries are correct. (There may be a delay before labels appear) * Apply Subversion release tag. (See [#SubversionReleaseTag Subversion Release Tag]) * 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): {{{ cd <snapshot-directory> 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. See [wiki:ReleasePractices/HeadsUpMessages#Boostn.nn.nReleaseNotice sample release notice]. Post as separate messages to: boost, boost-announce, boost-users, comp.lang.c++.moderated, c++std-news == Subversion Beta and Release Tags == With TortoiseSVN: * Do a log on an updated local working copy of branches/release. * Select the revision number for the release; right-click and select "Create branch/tag from revision". * To URL: https://svn.boost.org/svn/boost/tags/release/Boost_n_nn_n_beta1 * Specific revision in repository: should already be set to correct revision number. * '''Log message: Release n.n.n beta 1''' * Click OK ---- 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.