aboutsummaryrefslogtreecommitdiffstats
path: root/release-checklist.md
blob: 59fa7623dbe2fc1831613989d39fb9efd3396fa4 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
# Release Checklist

## Check out release versions

  - Check out the versions of pathod, netlib and mitmproxy due to be released

  - Verify that repositories are in a clean state:
    `./build git status`

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

  - Render the docs, update CONTRIBUTORS file:  
    `./build docs contributors`


## Test

  - Test the source distributions:  

        `./build test`  

    This does the following:
        - creates a venv in release/venv
        - creates source distributions in release/release
        - installs the source distributions in the venv
        - and runs all installed tools


## Release

  - Make a release commit for all projects, tag and push it:
    `./build git commit -am "Release v0.13"`
    `./build git tag v0.13`  
    `./build git push --tags`

  - 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:  
    `./build upload`  
    You can test with [testpypi.python.org](https://testpypi.python.org/pypi) by passing `--repository test`.
    ([more info](https://tom-christie.github.io/articles/pypi/))

  - 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.

  - Bump the version number in `version.py` for all projects:  
    `./build set-version 0.13`

    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)`