2016-10-26 06:48:03 +00:00
# Release Checklist
2018-05-16 23:15:15 +00:00
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.
2017-03-15 21:36:58 +00:00
- Verify `mitmproxy/version.py`
2017-02-21 17:37:56 +00:00
- Update CHANGELOG
2017-03-15 21:36:58 +00:00
- Verify that all CI tests pass
2018-05-16 23:15:15 +00:00
- 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`
2017-03-15 21:36:58 +00:00
- Tag the release and push to Github
2018-05-16 23:15:15 +00:00
- 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`
2016-10-26 06:48:03 +00:00
- Wait for tag CI to complete
2017-03-15 21:36:58 +00:00
## GitHub Release
2017-04-28 12:24:57 +00:00
- Create release notice on Github [here ](https://github.com/mitmproxy/mitmproxy/releases/new )
2018-05-16 23:15:15 +00:00
- 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
2017-03-15 21:36:58 +00:00
## PyPi
2018-05-16 23:15:15 +00:00
- Upload the whl file you downloaded in the prevous step
- `twine upload ./tmp/snap/mitmproxy-4.0.0-py3-none-any.whl`
2018-02-25 16:49:54 +00:00
## Homebrew
2018-05-16 23:15:15 +00:00
- **FIXME** This process does not work with 2FA.
2018-02-25 16:49:54 +00:00
- `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.
2017-03-15 21:36:58 +00:00
## Docker
2016-11-22 22:11:57 +00:00
- Update docker-releases repo
2017-03-04 10:50:21 +00:00
- Create a new branch based of master for major versions.
2017-03-15 21:36:58 +00:00
- Update the dependencies in [alpine/requirements.txt ](https://github.com/mitmproxy/docker-releases/commit/3d6a9989fde068ad0aea257823ac3d7986ff1613#diff-9b7e0eea8ae74688b1ac13ea080549ba )
* Creating a fresh venv, pip-installing the new wheel in there, and then export all packages:
2018-03-31 15:25:21 +00:00
* `virtualenv -ppython3.6 venv && source venv/bin/activate && pip install mitmproxy && pip freeze`
2017-04-30 09:21:28 +00:00
- Tag the commit with the correct version
2018-05-16 23:15:15 +00:00
* `v2.0.0` for new major versions
* `v2.0.2` for new patch versions
2017-04-30 09:21:28 +00:00
- Update `latest` tag [here ](https://hub.docker.com/r/mitmproxy/mitmproxy/~/settings/automated-builds/ )
2018-02-25 16:33:06 +00:00
- Check that the build for this tag succeeds [https://hub.docker.com/r/mitmproxy/mitmproxy/builds/ ](here )
- 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
2018-04-05 16:26:55 +00:00
## Website
- Update version here: https://github.com/mitmproxy/www/blob/master/src/config.toml
- `./build && ./upload-test`
- If everything looks alright: `./upload-prod`
2018-05-16 23:15:15 +00:00
## Docs
- Make sure you've uploaded the previous version's docs to archive
- If everything looks alright:
- `./build-current`
- `./upload-stable`
2018-02-22 13:21:46 +00:00
## Prepare for next release
- Last but not least, bump the version on master in [https://github.com/mitmproxy/mitmproxy/blob/master/mitmproxy/version.py ](mitmproxy/version.py ) for major releases.
