ReleasePreparationGuide

mlpack Release Preparation Guide

There are some things to be done before a release which are easy to forget but shouldn't be forgotten. A simple guide is here:

1. Ensure all supported configurations compile and the tests work on the build server.
2. Check the Windows build.
3. Ensure authors/copyright files are correct in tags/mlpack-x.y.z/.
4. Document new features in HISTORY.txt, and don't forget to include ticket numbers where relevant.
5. Either checkout release branch (mlpack-A.B.x) or create new branch from master if changes are significant enough.
6. Remove any features which are not meant to be released, and/or git cherry-pick from master or other branches as necessary.
7. Modify CMakeLists.txt so the default is DEBUG=OFF and PROFILE=OFF.
8. Change PROJECT_NUMBER to x.y.z in Doxyfile.
9. Update versions in src/mlpack/core/util/version.hpp.
10. Update src/mlpack/CMakeLists.txt so that VERSION and SOVERSION are right.
11. Add license to all files.
12. git archive --prefix=mlpack-A.B.x/ mlpack-A.B.x | gzip > mlpack-x.y.z.tar.gz
13. Copy the .tar.gz to mlpack.org/files/.
14. Increment the version on the website index page and download.html.
15. Update history.html on mlpack website with newest changes.
16. Rebuild documentation for x.y.z and push to mlpack.org.
17. Update docs.html with newest version.
18. Send announcement to mlpack list and post announcement on MLOSS.
19. Add release notes to Github page.
20. Start the benchmark build and try to remember to check on it in two weeks (actually, this is probably the first thing you should do, but too late now, right?).
21. Drink.

Push to distributions

Fedora

1. Get git source: fedpkg clone mlpack.
2. Get new mlpack version: wget http://www.mlpack.org/files/mlpack-x.y.z.tar.gz.
3. Push tarball to lookaside cache: fedpkg new-sources mlpack-x.y.z.tar.gz.
4. Update spec file; build locally (rpmbuild -ba mlpack.spec) and make sure everything seems okay. It may be useful to mock build for EPEL (since that can be picky sometimes).
5. Commit changes; git commit -a.
6. For each release of Fedora/EPEL, fedpkg switch-branch <release>; git merge master; git push; fedpkg build; fedpkg update.
7. When the waiting period is over for each update, push to stable (3-7 days for Fedora, 2 weeks for EPEL).

Push new benchmarks to website

We need to rebuild the benchmark reports so that the figure colors are right for the webpage.

1. Check out the benchmarking system to some directory.
2. Download massif.tar.gz and benchmark.db from the artifacts of the build server's [http://big.cc.gt.atl.ga.us:8080/job/benchmark%20-%20reports/ completed "benchmark - reports" job]
3. Put benchmark.db in the reports/ folder, and unpack the .mout files from massif.tar.gz into reports/etc/
4. Modify config.yaml; change chartColor to #000000, topChartColor to #000000, and textColor to #aaaaaa (the same color as the website text).
5. Run 'make reports' from the base benchmark directory.
6. Access the created file, reports/index.html, in a browser and take a look to make sure everything is okay.
7. Save the old benchmark.html on www.mlpack.org to some different file (for reference).
8. Copy index.html to www.mlpack.org:/var/www/www.mlpack.org/benchmark.html and all the support files too.
9. Use vimdiff to copy changes from benchmark-old.html to benchmark.html. This should include loading another css stylesheet, adding the header and navigation menu to the top of the page, and removing the top graph (because it might be confusing to users who aren't sure what it means).
10. Change the version in the phrase "This page contains benchmarks for the various algorithms implemented in mlpack x.y.z."