Skip to content

Commit 7d7673c

Browse files
authored
Add HOW_TO_RELEASE guidelines (#948)
For the benefit of jhamman, and anyone else who may eventually step up to be a maintainer!
1 parent 1c31332 commit 7d7673c

File tree

1 file changed

+70
-0
lines changed

1 file changed

+70
-0
lines changed

HOW_TO_RELEASE

Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
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

Comments
 (0)