-
Notifications
You must be signed in to change notification settings - Fork 239
Release Process
Update the version in the following files for the packages that are being released.
setup.py
_constants.py
The change logs/
ChangeLog.md
BreakingChanges.md
The documentation configuration has two strings for version and release
doc/conf.py
Test modes are configured in tests/settings_real.py
- Go to the tests/recordings folder and delete the old recordings. Make new recordings by setting the test mode to 'Record'. The test recordings include the version number in the User-Agent header of each request as well as the service version in the x-ms-version header.
- Run the tests in Playback mode after recording to make sure the recording succeeded. For faster validation, submit a PR to the repo and let Travis run the recordings in all languages.
- Do a pull request from dev to master.
- Create a new release, set the contents to the change log entry for the new version.
Update the Python samples and the Azure.com Python articles, if necessary.
-
Trigger rebuild of readthedocs.org. This should happen as part of a push, but if not you can go to ReadTheDocs and trigger a build manually.
-
Instructions for GitHub.io. We don't do this anymore. To publish the docs to GitHub.io:
- Build the docs using doc/BuildDocs.bat. Copy the output from the doc/_build/html folder to elsewhere.
- In your local copy of the public repo, switch to the gh-pages branch and make sure it is up to date with the public repo. If you're updating docs for the first time, ensure that your local gh-pages branch correctly tracks the remote gh-pages branch and does not mistakenly contain the history of the dev branch.
- Paste the contents of the html folder into the gh-pages branch.
- Commit the changes and do a pull request to the public repo. After a couple minutes, the updates should appear on GitHub.io.
Run the following command to build all the packages:
>python tool_build_packages.py all
This will create the source distribution files (.tar.gz) in the /dist folder and the universal wheel files (.whl) that works for both Python 2.x and 3.x.
If you get an general error when creating the wheel, make sure that your setup.py files don't have a Unicode BOM and then re-run the original setup.py file.
Once you've uploaded to PyPI, there's no way to overwrite the package. In case of problems, you'll need to increment the version number. To make sure everything works fine, first test locally, then upload and test installing from the test server, before finally upload and test from the production server.
- Create an account on the production server.
- Create an account on the test server with the same username/password.
- Get added as a project owner for azure-storage-* for both prod & test environments.
- Create a .pypirc file in your home directory:
[distutils]
index-servers =
pypi
test
[pypi]
username=<yourusername>
password=<yourpassword>
[test]
repository=https://test.pypi.org/legacy/
username=<yourusername>
password=<yourpassword>
To upload the library to the test server run:
>twine upload -r test dist/*.tar.gz
>twine upload -r test dist/*.whl
Note: If you don't have twine, run:
>pip3 install twine
Beware of the pip cache! If you see a message like this while testing installation of the package you've uploaded to pip:
Using cached azure_storage-0.20.0-py2.py3-none-any.whl
Then delete the %localappdata%/pip folder and test again.
Test locally using both Python 2 and Python 3. The virtual environments should help you localize problems. Basically venv creates a directory where all the packages could be installed. The directory also contains different python and pip versions. In the virtual environment, you can install from a local file, from the test server, or real server. See below for an example.
Python 3:
>python3 -m venv py3test
<Validate the library. See below.>
Python 2:
>virtualenv py2test
<Validate the library. See below.>
>source py3test/bin/activate
>pip install -r requirements.txt
>pip install azure-storage-blob -i https://testpypi.python.org/pypi --no-deps
# repeat for azure-storage-table and azure-storage-queue
$ python
Python 3.6.1 (v3.6.1:69c0db5050, Mar 21 2017, 01:21:04)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>import azure.storage.common
>>>account = azure.storage..common.CloudStorageAccount("accountName", "accountKey")
>>> bs = account.create_block_blob_service()
>>> bs.create_container("testy")
True
>>> bs.delete_container("testy")
True
>>> print("This is the version " + azure.storage.common.__version__)
This is the version 0.34.3
>>>
ctrl-d
>deactivate
To upload the library to production server run:
>twine upload dist/*.tar.gz
>twine upload dist/*.whl
To install from production:
>pip install azure-storage-blob
To save time, use the script tool_validate_packages.py to validate release contents:
python3 tool_validate_packages.py --python-version=2 --run-tests=true --create-package=false --environment prod
# view instructions
python3 tool_validate_package.py --help
The azure bundle package installs a specific version of the azure-storage package.
Contact the Azure SDK for Python team to update the azure bundle package. https://github.com/Azure/azure-sdk-for-python/wiki/Bundle-update-process
- Post to python-announce-list@python.org