Grasscutters/mitmproxy
3
0
Fork 0
mirror of https://github.com/Grasscutters/mitmproxy.git synced 2024-11-27 02:24:18 +00:00
Code Issues Projects Releases Wiki Activity
c3fffe152e
mitmproxy/release-checklist.md
Aldo Cortesi 20d89cd34f Initial checkin
2015-08-16 12:39:06 +12:00

2.3 KiB
Raw Blame History

Release Checklist

Test

  • Create the source distributions, make sure the output is sensible:
    ./release/build.py release
    All source distributions can be found in ./dist.

  • Test the source distributions:
    ./release/build.py test
    This creates a new virtualenv in ../venv.mitmproxy-release and installs the distributions from ./dist into it.

Release

  • Verify that repositories are in a clean state: ./release/build.py git status

  • Update the version number in version.py for all projects:
    ./release/build.py set-version 0.13

  • Ensure that the website style assets have been compiled for production, and synced to the docs.

  • Render the docs, update CONTRIBUTORS file:
    ./release/build.py docs contributors

  • Make version bump commit for all projects, tag and push it: ./release/build.py git commit -am "bump version" ./release/build.py git tag v0.13
    ./release/build.py git push --tags

  • Recreate the source distributions with updated version information:
    ./release/build.py sdist

  • Build the OSX binaries

    • Follow instructions in osx-binaries
    • Move to download dir:
      mv ./tmp/osx-mitmproxy-VERSION.tar.gz ~/mitmproxy/www.mitmproxy.org/src/download

  • Move all source distributions from ./dist to the server:
    mv ./dist/* ~/mitmproxy/www.mitmproxy.org/src/download

  • Upload distributions in ./dist to PyPI:
    ./release/build.py upload
    You can test with testpypi.python.org by passing --repository test. (more info)

  • Now bump the version number to be ready for the next cycle:

    TODO: We just shipped 0.12 - do we bump to 0.12.1 or 0.13 now? We should probably just leave it as-is and only bump once we actually do the next release.

    Also, we need a release policy. I propose the following:

    • By default, every release is a new minor (0.x) release and it will be pushed for all three projects.
    • Only if an emergency bugfix is needed, we push a new 0.x.y bugfix release for a single project. This matches with what we do in setup.py: "netlib>=%s, <%s" % (version.MINORVERSION, version.NEXT_MINORVERSION)