|
| 1 | +How to issue an xarray release in 15 easy steps |
| 2 | + |
| 3 | +Time required: about an hour. |
| 4 | + |
| 5 | + 1. Ensure your master branch is synced to upstream: |
| 6 | + git pull upstream master |
| 7 | + 2. Look over whats-new.rst and the docs. Make sure "What's New" is complete |
| 8 | + (check the date!) and add a brief summary note describing the release at the |
| 9 | + top. |
| 10 | + 3. Update the version in setup.py and switch to `ISRELEASED = True`. |
| 11 | + 4. If you have any doubts, run the full test suite one final time! |
| 12 | + py.test |
| 13 | + 5. On the master branch, commit the release in git: |
| 14 | + git commit -a -m 'Release v0.X.Y' |
| 15 | + 6. Tag the release: |
| 16 | + git tag -a v0.8.1 -m 'v0.X.Y' |
| 17 | + 7. Build source and binary wheels for pypi: |
| 18 | + python setup.py bdist_wheel sdist |
| 19 | + 8. Use twine to register and upload the release on pypi. Be careful, you can't |
| 20 | + take this back! |
| 21 | + twine register dist/xarray-0.X.Y-py2.py3-none-any.whl |
| 22 | + twine upload dist/xarray-0.X.Y* |
| 23 | + You will need to be listed as a package owner at |
| 24 | + https://pypi.python.org/pypi/xarray for this to work. |
| 25 | + 9. Push your changes to master: |
| 26 | + git push upstream master |
| 27 | + git push upstream --tags |
| 28 | + 9. Update the stable branch (used by ReadTheDocs) and switch back to master: |
| 29 | + git checkout stable |
| 30 | + git rebase master |
| 31 | + git push upstream stable |
| 32 | + git checkout master |
| 33 | + We also update the stable branch with `git cherrypick` for documentation |
| 34 | + only fixes that apply the current released version. |
| 35 | +10. Revert ISRELEASED in setup.py back to False. Don't change the version |
| 36 | + number: in normal development, we keep the version number in setup.py as the |
| 37 | + last releaseld version. |
| 38 | +11. Commit your changes and push to master again: |
| 39 | + git commit -a -m 'Revert to dev version' |
| 40 | + git push upstream master |
| 41 | + You're done pushing to master! |
| 42 | +12. Issue the release on GitHub. Click on "Draft a new release" at |
| 43 | + https://github.com/pydata/xarray/releases and paste in the latest from |
| 44 | + whats-new.rst. |
| 45 | +13. Update the docs. Login to https://readthedocs.org/projects/xray/versions/ |
| 46 | + and switch your new release tag (at the bottom) from "Inactive" to "Active". |
| 47 | + It should now build automatically. |
| 48 | +14. Update conda-forge. Clone https://github.com/conda-forge/xarray-feedstock |
| 49 | + and update the version number and sha256 in meta.yaml. (On OS X, you can |
| 50 | + calculate sha256 with `shasum -a 256 xarray-0.X.Y.tar.gz`). Submit a pull |
| 51 | + request (and merge it, once CI passes). |
| 52 | +15. Issue the release announcement! For bug fix releases, I usually only email |
| 53 | + [email protected]. For major/feature releases, I will email a broader |
| 54 | + list (no more than once every 3-6 months): |
| 55 | + |
| 56 | + |
| 57 | + |
| 58 | + Google search will turn up examples of prior release announcements (look for |
| 59 | + "ANN xarray"). |
| 60 | + |
| 61 | +Note on version numbering: |
| 62 | + |
| 63 | +We follow a rough approximation of semantic version. Only major releases (0.X.0) |
| 64 | +show include breaking changes. Minor releases (0.X.Y) are for bug fixes and |
| 65 | +backwards compatible new features, but if a sufficient number of new features |
| 66 | +have arrived we will issue a major release even if there are no compatibility |
| 67 | +breaks. |
| 68 | + |
| 69 | +Once the project reaches a sufficient level of maturity for a 1.0.0 release, we |
| 70 | +intend to follow semantic versioning more strictly. |
0 commit comments