[[PageOutline]] = Release Manager Checklists = == Introduction == == Release cycle initialization == * Update Trac milestones: https://svn.boost.org/trac/boost/admin/ticket/milestones * In boost super-project branch develop, change version number in: * root/Jamroot (1 place) * root/more/getting_started/detail/release-variables.rst (4 places) * In root/more/getting_started, run `b2`. * Inspect results. * Create a pull request for `config`: * include/boost/version.hpp (2 places) - Note that `BOOST_LIB_VERSION` should not include the patch version if it's zero. * Commit version number and Getting Started doc changes: * Commit develop, push. * Merge develop to master (wait for config?). * Commit master, push. * Update the Google calendar as described in [https://github.com/boostorg/boost/wiki/Release-Schedule the Release Schedule] so that it is always several releases ahead. '''This is really important; it causes endless trouble if the calendar isn't updated.''' * Post the "Open for merges" heads up message. See [wiki:ReleasePractices/HeadsUpMessages 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@yahoogroups.com that `b2` pre-built executables up-to-date. * Create a placeholder for release information at: website/public_html/live/feed/history/, for example for boost 1.60.0: {{{ git clone git@github.com:boostorg/website.git live-website cd live-website cp feed/templates/boost_x_xx_x.qbk feed/history/boost_1_60_0.qbk # Edit the version number (in two places) in the new entry python site-tools/update.py git add feed/history/boost_1_60_0.qbk git commit -a -m "Stub release notes for 1.60.0" git push }}} This only updates the 'in progress' release notes. The proper release notes are created for the first beta. == 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 == === Create !GitHub Repository Before a release manager creates a [https://github.com/boostorg boostorg GitHub] repository for the new library, the release manager should send an email to developer: * Ask the developer to read this checklist (i.e. https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList#NewLibraryChecklist) so that he or she will be aware of the steps that will have to be completed to add a library to the Boost distributions. * Ask for the !GitHub user-id of the developer and anyone else to be given read-write access to the library's repository. The release manager performs two steps to add the new library to [https://github.com/boostorg GitHub]: * Do one of two things: * If the library already has a !GitHub repository, [https://help.github.com/articles/transferring-a-repository/ transfer the repository to boostorg]. Getting the maintainer to transfer into the organization is a bit awkward. So it might be best to first transfer the repo to an admin, who can then transfer it into the organization and set up the team. * If the library does not already have a !GitHub repository, [https://github.com/organizations/boostorg/repositories/new Create the library's repository]. Note: the release manager creates a repository that is empty except for a readme file. The library's developer is responsible for creating the library's contents. * Go into the repo settings, and make sure the owner has admin permissions. === Add library as a submodule on boost develop branch === Before a release manager adds the library as a submodule on the boost super-project develop branch, the release manager should verify the library is ready to start regression testing: * The critical elements of the library xxx directory structure are in place: * libs/xxx/include/boost/xxx has the header files. * libs/xxx/test has a Jamfile.v2, and {{{b2}}} works. Tests don't have to pass, but the Jamfile needs to be in good enough shape that it will not break regression testing. * If it is a compiled library, libs/xxx/build has a Jamfile.v2 in in good enough shape that it will not break regression testing. * The directory structure in general is reasonably complete and boost-like. * Run inspect and verify the report is not a total disaster. It does not have to be totally clean, but it should be clean enough to indicate the developer has the general idea of what is required. === Add library as a submodule on boost master branch === Before a release manager adds the library as a submodule on the boost super-project master branch, the release manager should verify: * The formal review manager is satisfied any requirements for inclusion set by the formal review have been met. * The repo contains an `index.html` file with either the main docs or a redirection to the main docs. * [http://www.boost.org/development/library_metadata.html `meta/libraries.json`] is present in the repo and contents look reasonable. * 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. * Inspection report is clean. * Regression on develop tests are reasonably clean. After a new library is merged into master, 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/live/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 == Verify index.html have been updated with the number of new libraries, at http://www.boost.org/doc/libs/master/index.html 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/live/feed/history/boost_n_nn_0.qbk == Between Beta and Release == See ReleasePractices/PostBetaMerges == Build Distribution Packages == * Up to date instructions on [https://github.com/boostorg/boost/wiki/Preparing-Releases GitHub wiki]. * '''''Important''''': Post request for review of release candidates. See [wiki:ReleasePractices/HeadsUpMessages#n.nn.nReleasecandidatesavailable sample candidates avaiable notice]. == Releases == * '''''Important''''': Release team must have signed off on packages. Ignoring this in the past has led to mistakes! * Instructions for uploading to bintray on [https://github.com/boostorg/boost/wiki/Preparing-Releases GitHub wiki]. * 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 README file from trunk/tools/release/README * 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. * 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 }}} * Windows only: run: chg n.nn.n.md5 "\r" "" // strip "\r" or md5sum can't find files * Run: md5sum -c -w