Release Checklist

Before a new release

• clear the bug queue, move everything which will not be part of the release to a new milestone.
• Make sure the builds are green across all platforms we monitor: linux, windows, macosx.
• Do an asv comparison against previous releases to catch perf regressions.
• Review Experimental features from previous releases and see what's ready to mark as stable. Update docstring/docs as necessary and document in release notes. Make sure Experimental features are documented as such in the release notes/docs.
• Clean up release.rst and whatsnew.rst, make sure no all needed commits are documented. run a spellcheck.
• Run a full doc build and make sure everything is clean: ./make.py clean; ./make.py; ./make.py zip_html; ./make.py latex_forced Check the output, check whatsnew and release.rst for formatting errors.
• run build_dist.sh, uninstall cython and make a test install of the tarball to ensure cython is not required for installation from tarball/pypi (now also part of travis scripts, but check).
• Open a pre-release issue and mention related parties. Send a headsup to pandas-dev. This should be at least a few days to a week before the release.

Updating pandas-website

• clone the repo: https://github.com/pydata/pandas-website.git
• update the .rst files and _themes/pydata/layout.html when adding a new version
• commit and push
• on the pydata.org server (can also push/pull from the server):
  • go to /www/pandas
  • pull the repo
  • build the docs: python make.py
  • refresh the server: python upload.py (it should update almost immediately)

Release candidate

• Make an empty commit: git commit --allow-empty -m 'RLS: v0.18.0rc2'
• Tag the commit using an annotated tag. git tag -a v0.18.0rc2 -m "Version 0.18.0rc2"
• push the RLS commit!
• Push the tag! git push --tags https://github.com/pydata/pandas.git master.
• build_dist.sh & generate windows binaries. / generate conda packages
• Create a new github release: https://github.com/pydata/pandas/releases, and upload
• Send out a release candidate announcement similar to below (except for the python-announce list)
• Samples:
  • 0.18rc2
  • 0.18rc1
  • 0.17rc2
  • 0.17rc1
  • 0.16rc1
  • 0.15rc1
  • 0.14rc1
  • 0.13rc1
  • scipy 0.14rc
  • numpy 1.6rc

When releasing

• Call a hold on master in the pre-release issue before you start.
• Get commits since last release:
  git log v0.18.0.. --format='%an#%s' | grep -v Merge > commits
• Include a summary by contributor in release notes:
  cat commits | gawk -F '#' '{ print "- " $1 }' | sort | uniq
• Stats run release_stats.sh
• In release notes/whatsnew, update release date.
• Make an empty commit: git commit --allow-empty -m "RLS: v0.18.1"
• Tag using an annotated tag. git tag -a v0.18.1 -m "Version 0.18.1"
• Double check everything. Once you push the commit there's no changing history.
• Push the commits git push https://github.com/pydata/pandas.git master
• Push the tag! git push --tags https://github.com/pydata/pandas.git master.
• This will cause a new release on github, which will cause folks (grokhle) to create the windows binaries and (matthew brett) to generate mac wheels. Edit the release to have the ANN message, then publish it. You may have to re-edit to have the correct doc pointers (to release docs)
• Windows Builds
  • Built automatically when the release is published (takes a couple of hours)
  • Download from here
• Mac Wheels
  • Rerun the travis build to create the mac wheels here
  • Download mac wheels from here
  • Original reference to this process here
• Upload new docs to website server, archive a copy of the new version in the appropriate dir.
• Update pandas-website with blurbs and links, push to GH, upload to website server.
• Make sure the pdf and zipped HTML links on the documentation front page are available.
  • Check that the version string are correct.
  • check that the pdf bookmarks are correct (latex requires multiple passes).
• Create, this generates a dist/ with the built *.c and files
  • build_dist.sh.
• Upload
  • you can use twine upload * to upload tarballs and all of the wheels
  • Hide the release until the windows binaries are available, then show it.
• Upload binaries/wheels (when available) to PyPi & github.
• Close the Milestone on github

Start the new cycle

• Setup up a new empty doc/v0.18.2.txt for the next expected version. and make a new commit to start the new cycle.
• Update for new version strings in ci/appveyor.recipe/meta.yaml

Update pandas-website

• clone pandas-website
• update _static\pydata\layout.html to include the new versions
• update index.rst to highlite the new release
• commit and push
• login pandas.pydata.org
• pull in the changes
• build the docs python make.py html
• restart web service python upload.py from ~/www

The announcement

• Make sure everything is in place
  • pypi binaries for windows, mac wheels, source
  • docs built and published
  • website updated
• Send an ANN to the mailing list. include links to both release notes and whatsnew.
• Include highlights, important changes and and preview upcoming features in the next release.
• Specify expected date for next release.
• Include links to pypi, binaries, docs, whatsnew and full release notes.
• Include a Thanks section
• Samples here:
  • 0.18.0
  • 0.17.1
  • 0.17.0
  • 0.16.2
  • 0.16.1
  • 0.16.0
  • 0.15.2
  • 0.15.1
  • 0.15.0
  • 0.14.1
  • 0.14.0
  • 0.13.1
  • 0.13.0
  • 0.11.0
• send announcements to [email protected], [email protected], [email protected], [email protected], [email protected]

Release engineering

• Before a major release, we do an RC.
• after the RC there is a feature freeze in effect.
• When a major version is release, a cooldown period is in effect. No breaking changes allowed until a bugfix release is out or the team decides to skip doing it. (Wait minimum two-three weeks after major release to gather critical bug reports).
• Review shipped versions of big dependencies (numpy, scipy, etc) for the big distros, adjust env versions of travis to make sure we have coverage for the common env users run pandas in.