PyPy’s Release Process

Release Policy

We try to create a stable release a few times a year. These are released ona branch named like release-pypy3.5-v2.x or release-pypy3.5-v4.x, and eachrelease is tagged, for instance release-pypy3.5-v4.0.1.

The release version number should be bumped. A micro release increment meansthere were no changes that justify rebuilding c-extension wheels, sincethe wheels are marked with only major.minor version numbers. It is ofen notclear what constitues a “major” release verses a “minor” release, the releasemanager can make that call.

After release, inevitably there are bug fixes. It is the responsibility ofthe commiter who fixes a bug to make sure this fix is on the release branch,so that we can then create a tagged bug-fix release, which will hopefullyhappen more often than stable releases.

How to Create a PyPy Release

As a meta rule setting up issues in the tracker for items here may help notforgetting things. A set of todo files may also work.

Check and prioritize all issues for the release, postpone some if necessary,create new issues also as necessary. An important thing is to getthe documentation into an up-to-date state!

Release Steps

Make the release branch

This is needed only in case you are doing a new major version; if not, you canprobably reuse the existing release branch.

We want to be able to freely merge default into the branch and vice-versa;thus we need to do a complicate dance to avoid to patch the version numberwhen we do a merge:

  1. $ hg up -r default
  2. $ # edit the version to e.g. 7.0.0-final
  3. $ hg ci
  4. $ hg branch release-pypy2.7-v7.x && hg ci
  5. $ hg up -r default
  6. $ # edit the version to 7.1.0-alpha0
  7. $ hg ci
  8. $ hg up -r release-pypy2.7-v7.x
  9. $ hg merge default
  10. $ # edit the version to AGAIN 7.0.0-final
  11. $ hg ci

Then, we need to do the same for the 3.x branch:

  1. $ hg up -r py3.5
  2. $ hg merge default # this brings the version fo 7.1.0-alpha0
  3. $ hg branch release-pypy3.5-v7.x
  4. $ # edit the version to 7.0.0-final
  5. $ hg ci
  6. $ hg up -r py3.5
  7. $ hg merge release-pypy3.5-v7.x
  8. $ # edit the version to 7.1.0-alpha0
  9. $ hg ci

To change the version, you need to edit three files:

  • module/sys/version.py
  • module/cpyext/include/patchlevel.h
  • doc/conf.py

Other steps

  • Make sure the RPython builds on the buildbot pass with no failures

  • Maybe bump the SOABI number in module/imp/importing. This has manyimplications, so make sure the PyPy community agrees to the change.Wheels will use the major.minor release numbers in the name, so bumpthem if there is an incompatible change to cpyext.

  • Update and write documentation

    • update pypy/doc/contributor.rst (and possibly LICENSE)pypy/doc/tool/makecontributor.py generates the list of contributors
    • rename pypy/doc/whatsnew_head.rst to whatsnew_VERSION.rstcreate a fresh whatsnew_head.rst after the releaseand add the new file to pypy/doc/index-of-whatsnew.rst
    • write release announcement pypy/doc/release-VERSION.rstThe release announcement should contain a direct link to the download page
    • Add the new files to pypy/doc/index-of-{whatsnew,release-notes}.rst

  • Build and upload the release tar-balls

    • go to pypy/tool/release and runforce-builds.py <release branch>The following JIT binaries should be built, however, we need more buildbotswindows, linux-32, linux-64, osx64, armhf-raspberrian, armel,freebsd64

    • wait for builds to complete, make sure there are no failures

    • send out a mailing list message asking for people to test before uploadingto prevent having to upload more than once

    • add a tag on the pypy/jitviewer repo that corresponds to pypy release, sothat the source tarball can be produced in the next steps

    • download the builds, repackage binaries. Tag the release-candidate version(it is important to mark this as a candidate since usually at least twotries are needed to complete the process) and download and repackage sourcefrom bitbucket. You may find it convenient to use the repackage.shscript in pypy/tool/release to do this.

Otherwise repackage and upload source “-src.tar.bz2” to bitbucketand to cobra, as some packagers prefer a clearly labeled source package( download e.g. https://bitbucket.org/pypy/pypy/get/release-2.5.x.tar.bz2,unpack, rename the top-level directory to “pypy-2.5.0-src”, repack, and upload)

  • Send out a mailing list message asking for last-minute comments and testing

  • RELEASE !

    • update pypy.org (under extradoc/pypy.org), rebuild and commit, using thehashes produced from the repackage.sh script or by hand
    • post announcement on morepypy.blogspot.com
    • send announcements to twitter.com, pypy-dev, python-list,python-announce, python-dev …

  • If all is OK, document the released version