Skip to content
David Stephens edited this page Mar 28, 2015 · 3 revisions

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, sparc (debian), and freebsd.
  • 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 python setup.py sdist, 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.
  • Add the rc-release to pandas-datareader's .travis.yml

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 the RLS commit, bumping to the new released tag (major and/or minor), set ISRELEASED=True, set the qualifier to rc1
  • Tag the commit using an annotated tag. git tag -a v0.y.zrc1 -m "Version 0.y.zrc1
  • push the RLS commit!
  • Push the tag! git push --tags https://github.com/pydata/pandas.git master.
  • python setup.py sdist --formats=zip,gztar & generate windows binaries.
  • 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:
  • push an ISRELEASED=False commit

When releasing

  • Call a hold on master in the pre-release issue before you start.
  • Include a summary by contributor in release notes: git log v0.15.2.. --format='%an#%s' | grep -v Merge | gawk -F '#' '{ print "- " $1 }' | sort | uniq
  • [OLD INCLUDE] Include a summary count of commits included in the release by contributor. git log v0.15.2.. --format='%an#%s' | grep -v Merge | grep -Po '^.+?(?=#)' |sort | uniq -c | sort -nr
  • In release notes/whatsnew, update release date.
  • In setup.py update the version strings as needed and set ISRELEASED=True.
  • Make the RLS commit.
  • Tag the commit using an annotated tag. git tag -a v0.16.0 -m "Version 0.16.0" (this tags the latest commit which should be the RLS commit)
  • In setup.py update the version strings as needed and set ISRELEASED=False, setup up a new empty doc/v0.16.1.txt for the next expected version. and make a new commit to start the new cycle.
  • Double check everything. Once you push the commit there's no changing history.
  • Push the commits git push https://github.com/pydata/pandas-datareader.git master
  • Push the tag! git push --tags https://github.com/pydata/pandas-datareader.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. [NTD: Do we need this for data-reader?] 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 and upload to PyPi
    • git checkout <lastest_version>
    • python setup.py sdist --formats=zip,gztar upload.
    • It may be necessary to first register, python setup.py register, which creates the .pypirc permissions file.
    • 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

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

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.