The release process of the python client involves creating (or updating) a release branch, updating release tags, and creating distribution packages and uploading them to pypi.
Make sure the change logs are up to date here. If they are not, follow commits added after the last release and update/commit the change logs to master.
Then based on the release, follow one of next two steps.
The release branch name should have release-x.x format. All minor and pre-releases should be on the same branch. To update an existing branch with master (only for latest pre-release):
export RELEASE_BRANCH=release-x.y
git checkout $RELEASE_BRANCH
git fetch upstream
git rebase upstream/$RELEASE_BRANCH
git pull upstream master
You may need to fix some conflicts. For auto-generated files, you can commit either version. They will be updated to the current version in the next step.
If you are releasing a patch to an existing stable release, you should do a cherry pick first:
scripts/cherry_pick_pull.sh
Do not merge master into a stable release branch. Run the script without parameters and follow its instructions to create a cherry pick PR. Get the PR merged then update your local branch:
export RELEASE_BRANCH=release-x.y
git checkout $RELEASE_BRANCH
git fetch upstream
git rebase upstream/$RELEASE_BRANCH
We need to make sure there are no API changes after running update client scripts. Such changes should be committed to the master branch first. Run this command:
scripts/update-client.sh
And make sure there is no API change (version number changes should be fine as they will be updated in the next step anyway). Do not commit any changes at this step and go back to the master branch if there are any API changes.
Release tags are in the "scripts/constants.py" file. These are the constants you may need to update:
CLIENT_VERSION: Client version should follow x.y.zDn where x,y,z are version numbers (integers) and D is one of "a" for alpha or "b" for beta and n is the pre-release number. For a final release, the "Dn" part should be omitted. Examples: 1.0.0a1, 2.0.1b2, 1.5.1.
DEVELOPMENT_STATUS: Update it to one of the values of "Development Status" in this list.
after changing constants to proper versions, update the client using this command:
scripts/update-client.sh
and commit changes (should be only version number changes) to the release branch. Name the commit something like "Update version constants for XXX release".
git push upstream $RELEASE_BRANCH
First make sure you are using a clean version of python. Use virtualenv and pyenv packages. Make sure you are using python 2.7.12. I would normally do this on a clean machine:
(install pyenv) (install pip) (install virtualenv)
git clean -xdf
pyenv install -s 2.7.12
pyenv global 2.7.12
virtualenv .release
source .release/bin/activate
python --version # Make sure you get Python 2.7.12
pip install twine
Now we need to create a "~/.pypirc" with this content:
[distutils]
index-servers=pypi
[pypi]
repository = https://upload.pypi.org/legacy/
username = kubernetes
TODO: we should be able to pass these parameters to twine directly. My first attempt failed.
Now that the environment is ready, lets create distribution packages:
python setup.py sdist
python setup.py bdist_wheel --universal
ls dist/
You should see two files in dist folder: "kubernetes*.whl" and "kubernetes*.tar.gz".
TODO: We need a dry-run option and some way to test the package upload process to pypi.
If everything looks good, run this command to upload packages to pypi:
twine upload dist/*
Create a gihub release by starting from
this page.
Click the Draft a new release button
. Name the tag the same as CLIENT_VERSION. Change
the target branch to "release-x.y". If the release is a pre-release, check the
This is a pre-release
option.
Send an announcement email to [email protected] with the subject: [ANNOUNCE] kubernetes python-client $VERSION is released
deactivate
rm -rf .release
TODO: Convert steps in this document to an (semi-) automated script.