Maintainer / core-developer information

Before a release

  1. Update authors table:

    $ cd build_tools; make authors; cd ..

    and commit.

Making a release

For more information see

  1. Update docs:

    • Edit the doc/whats_new.rst file to add release title and commit statistics. You can retrieve commit statistics with:

      $ git shortlog -ns 0.998..
    • Edit the doc/index.rst to change the ‘News’ entry of the front page.

  2. Update the version number in sklearn/, the __version__ variable

  3. Create the tag and push it:

    $ git tag 0.999
    $ git push origin --tags
  4. create the source tarball:

    • Wipe clean your repo:

      $ git clean -xfd
    • Generate the tarball:

      $ python sdist

    The result should be in the dist/ folder. We will upload it later with the wheels. Check that you can install it in a new virtualenv and that the tests pass.

  5. Build binaries using dedicated CI servers by updating the git submodule reference to the new scikit-learn tag of the release at:

    Once the CI has completed successfully, collect the generated binary wheel packages and upload them to PyPI by running the following commands in the scikit-learn source folder (checked out at the release tag):

    $ pip install -U wheelhouse_uploader twine
    $ python fetch_artifacts

    Check the content of the dist/ folder: it should contain all the wheels along with the source tarball (“scikit-learn-XXX.tar.gz”).

    Make sure that you do not have developer versions or older versions of the scikit-learn package in that folder.

    Upload everything at once to

    $ twine upload dist/
  6. Push the documentation to the website. Circle CI should do this automatically for master and <N>.<N>.X branches.

  7. FOR FINAL RELEASE: Update the release date in What’s New

The web site

The scikit-learn web site ( is hosted at GitHub, but should rarely be updated manually by pushing to the repository. Most updates can be made by pushing to master (for /dev) or a release branch like 0.99.X, from which Circle CI builds and uploads the documentation automatically.

Travis Cron jobs

From Travis CI cron jobs work similarly to the cron utility, they run builds at regular scheduled intervals independently of whether any commits were pushed to the repository. Cron jobs always fetch the most recent commit on a particular branch and build the project at that state. Cron jobs can run daily, weekly or monthly, which in practice means up to an hour after the selected time span, and you cannot set them to run at a specific time.

For scikit-learn, Cron jobs are used for builds that we do not want to run in each PR. As an example the build with the dev versions of numpy and scipy is run as a Cron job. Most of the time when this numpy-dev build fail, it is related to a numpy change and not a scikit-learn one, so it would not make sense to blame the PR author for the Travis failure.

The definition of what gets run in the Cron job is done in the .travis.yml config file, exactly the same way as the other Travis jobs. We use a if: type = cron filter in order for the build to be run only in Cron jobs.

The branch targeted by the Cron job and the frequency of the Cron job is set via the web UI at