|
| 1 | +# Release process |
| 2 | + |
| 3 | +Release process of python client involve creating (or updating) a release |
| 4 | +branch, update release tags, create distribution packages and upload them to |
| 5 | +pip. |
| 6 | + |
| 7 | +## Change logs |
| 8 | +Make sure changes logs are up to date [here](https://github.com/kubernetes-incubator/client-python/blob/master/CHANGELOG.md). |
| 9 | +If they are not, follow commits added after last release and update/commit |
| 10 | +the change logs to master. |
| 11 | + |
| 12 | +## Release branch |
| 13 | + |
| 14 | +Release branch name should have release-x.x format. All minor and pre-releases |
| 15 | +should be on the same branch. To update an existing branch: |
| 16 | + |
| 17 | +```bash |
| 18 | +export RELEASE_BRANCH=release-x.x |
| 19 | +git checkout RELEASE_BRANCH |
| 20 | +git fetch upstream |
| 21 | +git pull upstream/master |
| 22 | +git push origin RELEASE_BRANCH |
| 23 | +``` |
| 24 | + |
| 25 | +You may need to fix some conflicts. For auto-generated files, you can commit |
| 26 | +either version. They will be updated to the current version in the next step. |
| 27 | + |
| 28 | +## Sanity check generated client |
| 29 | +We need to make sure there is no API changes after running update client |
| 30 | +scripts. Such changes should be committed to master branch first. Run this |
| 31 | +command: |
| 32 | + |
| 33 | +```bash |
| 34 | +scripts/update-client.sh |
| 35 | +``` |
| 36 | + |
| 37 | +And make sure there is no API change (version number changes should be fine |
| 38 | +as they will be updated in next step anyway). Do not commit any changes at |
| 39 | +this step and go back to master branch if there is any API changes. |
| 40 | + |
| 41 | +## Update release tags |
| 42 | + |
| 43 | +Release tags are in scripts/constants.py file. These are the constants you may |
| 44 | +need to update: |
| 45 | + |
| 46 | +CLIENT_VERSION: Client version should follow x.y.zDn where x,y,z are version |
| 47 | +numbers (integers) and D is one of "a" for alpha or "b" for beta and n is the |
| 48 | +pre-release number. For a final release, "Dn" part should be omitted. Examples: |
| 49 | +1.0.0a1, 2.0.1b2, 1.5.1 |
| 50 | +SPEC_VERSION: This would be the kubernetes OpenAPI spec version. It should be |
| 51 | +deprecated after kubernetes/kubernetes#37055 takes effect. |
| 52 | +DEVELOPMENT_STATUS: Update it to one of the values of "Development Status" |
| 53 | +in [this list](https://pypi.python.org/pypi?%3Aaction=list_classifiers). |
| 54 | + |
| 55 | +after changing constants to proper versions, update the client using this |
| 56 | +command: |
| 57 | + |
| 58 | +```bash |
| 59 | +scripts/update-client.sh |
| 60 | +``` |
| 61 | + |
| 62 | +and commit changes (should be only version number changes) to the release branch. |
| 63 | +Name the commit something like "Update version constants for XXX release". |
| 64 | + |
| 65 | +```bash |
| 66 | +git push upstream RELEASE_BRANCH |
| 67 | +``` |
| 68 | + |
| 69 | +## Make distribution packages |
| 70 | +First make sure you are using a clean version of python. Use virtualenv and |
| 71 | +pyenv packages, make sure you are using python 2.7.12. I would normally do this |
| 72 | +on a clean machine: |
| 73 | + |
| 74 | +(install [pyenv](https://github.com/yyuu/pyenv#installation)) |
| 75 | +(install [pip](https://pip.pypa.io/en/stable/installing/)) |
| 76 | +(install [virtualenv](https://virtualenv.pypa.io/en/stable/installation/)) |
| 77 | + |
| 78 | +```bash |
| 79 | +git clean -xdf |
| 80 | +pyenv install 2.7.12 |
| 81 | +pyenv global 2.7.12 |
| 82 | +virtualenv .release |
| 83 | +source .release/bin/activate |
| 84 | +python --version # Make sure you get Python 2.7.12 |
| 85 | +pip install twine |
| 86 | +``` |
| 87 | + |
| 88 | +Now we need to create a "~/.pypirc" with this content: |
| 89 | + |
| 90 | +``` |
| 91 | +[distutils] |
| 92 | +index-servers=pypi |
| 93 | +
|
| 94 | +[pypi] |
| 95 | +repository = https://upload.pypi.org/legacy/ |
| 96 | +username = kubernetes |
| 97 | +``` |
| 98 | + |
| 99 | +TODO: we should be able to pass these parameters to twine directly. My first attempt failed. |
| 100 | + |
| 101 | +Now that the environment is ready, lets create distribution packages: |
| 102 | + |
| 103 | +```bash |
| 104 | +python setup.py sdist |
| 105 | +python setup.py bdist_wheel --universal |
| 106 | +ls dist/ |
| 107 | +``` |
| 108 | + |
| 109 | +You should see two files in dist folder. kubernetes*.whl and kubernetes*.tar.gz. |
| 110 | + |
| 111 | +TODO: We need a dry-run option an some way to test package upload process to pypi. |
| 112 | + |
| 113 | +If everything looks good, run this command to upload packages to pypi: |
| 114 | + |
| 115 | +``` |
| 116 | +twine upload dist/* |
| 117 | +``` |
| 118 | + |
| 119 | +## Create github release |
| 120 | + |
| 121 | +Create a gihub release by starting from |
| 122 | +[this page(https://github.com/kubernetes-incubator/client-python/releases). |
| 123 | +Click Deaft new release button. Name the tag the same as CLIENT_VERSION. Change |
| 124 | +the target branch to "release-x.y" |
| 125 | + |
| 126 | + |
| 127 | +ref: https://packaging.python.org/distributing/ |
| 128 | + |
| 129 | +## Cleanup |
| 130 | + |
| 131 | +```bash |
| 132 | +deactivate |
| 133 | +rm -rf .release |
| 134 | +``` |
| 135 | + |
| 136 | +TODO: Convert steps in this document to an (semi-) automated script. |
0 commit comments