mitmproxy/release
Aldo Cortesi 052b378ea6 Post-release updates
- Update release docs
- Bump version
2018-05-17 18:28:43 +02:00
..
hooks fix appveyor build script 2017-12-30 18:48:49 +01:00
installbuilder InstallBuilder (#1826) 2016-12-11 23:07:47 +01:00
specs fix pyinstaller 2016-11-28 00:51:52 +01:00
windows-store-experiment minor fixes for windows package 2017-06-14 14:35:51 +02:00
.gitignore pin snapshot server hostkey, update pysftp 2018-01-04 14:12:30 +01:00
ci.py release: fix PR detection for appveyor 2018-03-08 09:52:05 +13:00
README.md Post-release updates 2018-05-17 18:28:43 +02:00
rtool.py Post-release updates 2018-05-17 18:28:43 +02:00

Release Checklist

Make sure run all these steps on the correct branch you want to create a new release for! The command examples assume that you have a git remote called upstream that points to the mitmproxy/mitmproxy repo.

  • Verify mitmproxy/version.py
  • Update CHANGELOG
  • Verify that all CI tests pass
  • Create a major version branch - e.g. v4.x. Assuming you have a remote repo called upstream that points to the mitmproxy/mitmproxy repo::
    • git checkout -b v4.x upstream/master
    • git push -u upstream v4.x
  • Tag the release and push to Github
    • For alphas, betas, and release candidates, use lightweight tags. This is necessary so that the .devXXXX counter does not reset.
    • For final releases, use annotated tags. This makes the .devXXXX counter reset.
      • git tag -a v4.0.0 -m v4.0.0
      • git push upstream v4.0.0
  • Wait for tag CI to complete

GitHub Release

  • Create release notice on Github here
  • Grab a copy of the current snapshot files from snapshots.mitmproxy.org:
    • aws s3 cp --recursive s3://snapshots.mitmproxy.org/vXXX/ .
  • Attach all files to the release

PyPi

  • Upload the whl file you downloaded in the prevous step
  • twine upload ./tmp/snap/mitmproxy-4.0.0-py3-none-any.whl

Homebrew

  • FIXME This process does not work with 2FA.
  • tox -e rtool -- homebrew-pr
  • The Homebrew maintainers are typically very fast and detect our new relese within a day, but we can be a nice citizen and create the PR ourself.

Docker

  • Update docker-releases repo
    • Create a new branch based of master for major versions.
    • Update the dependencies in alpine/requirements.txt
      • Creating a fresh venv, pip-installing the new wheel in there, and then export all packages:
      • virtualenv -ppython3.6 venv && source venv/bin/activate && pip install mitmproxy && pip freeze
    • Tag the commit with the correct version
      • v2.0.0 for new major versions
      • v2.0.2 for new patch versions
  • Update latest tag here
  • Check that the build for this tag succeeds https://hub.docker.com/r/mitmproxy/mitmproxy/builds/
  • If build failed:
    • Fix it and commit
    • git tag 3.0.2 the new commit
    • git push origin :refs/tags/3.0.2 to delete the old remote tag
    • git push --tags to push the new tag
    • Check the build details page again

Website

Docs

  • Make sure you've uploaded the previous version's docs to archive
  • If everything looks alright:
    • ./build-current
    • ./upload-stable

Prepare for next release