1
- # How to issue an xarray release in 17 easy steps
1
+ # How to issue an xarray release in 20 easy steps
2
2
3
3
Time required: about an hour.
4
4
5
+ These instructions assume that ` upstream ` refers to the main repository:
6
+ ```
7
+ $ git remote -v
8
+ {...}
9
+ upstream https://github.com/pydata/xarray (fetch)
10
+ upstream https://github.com/pydata/xarray (push)
11
+ ```
12
+
5
13
1 . Ensure your master branch is synced to upstream:
6
- ```
7
- git pull upstream master
8
- ```
14
+ ``` sh
15
+ git pull upstream master
16
+ ```
9
17
2. Get a list of contributors with:
10
- ```
18
+ ` ` ` sh
11
19
git log " $( git tag --sort=" v:refname" | sed -n ' x;$p' ) .." --format=%aN | sort -u | perl -pe ' s/\n/$1, /'
12
20
` ` `
13
- or by substituting the _previous_ release in:
14
- ```
15
- git log v0 .X.Y-1.. --format=%aN | sort -u | perl -pe 's/\n/$1, /'
21
+ or by substituting the _previous_ release in {0.X.Y-1} :
22
+ ` ` ` sh
23
+ git log v{0 .X.Y-1} .. --format=%aN | sort -u | perl -pe ' s/\n/$1, /'
16
24
` ` `
17
25
Add these into ` whats-new.rst` somewhere :)
18
- 3. Look over whats-new.rst and the docs. Make sure "What's New" is complete
19
- (check the date!) and consider adding a brief summary note describing the
20
- release at the top.
26
+ 3. Write a release summary: ~ 50 words describing the high level features. This
27
+ will be used in the release emails, tweets, GitHub release notes, etc.
28
+ 4. Look over whats-new.rst and the docs. Make sure " What's New" is complete
29
+ (check the date! ) and add the release summary at the top.
21
30
Things to watch out for:
22
31
- Important new features should be highlighted towards the top.
23
32
- Function/method references should include links to the API docs.
24
33
- Sometimes notes get added in the wrong section of whats-new, typically
25
34
due to a bad merge. Check for these before a release by using git diff,
26
- e.g., `git diff v0 .X.Y whats-new.rst` where 0.X.Y is the previous
35
+ e.g., ` git diff v{0 .X.Y-1} whats-new.rst` where { 0.X.Y-1} is the previous
27
36
release.
28
- 4. If you have any doubts, run the full test suite one final time!
29
- ```
37
+ 5. If possible, open a PR with the release summary and whatsnew changes.
38
+ 6. After merging, again ensure your master branch is synced to upstream:
39
+ ` ` ` sh
40
+ git pull upstream master
41
+ ` ` `
42
+ 7. If you have any doubts, run the full test suite one final time!
43
+ ` ` ` sh
30
44
pytest
31
45
` ` `
32
- 5. Check that the ReadTheDocs build is passing.
33
- 6. On the master branch, commit the release in git:
46
+ 8. Check that the ReadTheDocs build is passing.
47
+ 9. On the master branch, commit the release in git:
48
+ ` ` ` s
49
+ git commit -am ' Release v{0.X.Y}'
34
50
` ` `
35
- git commit -am 'Release v0.X.Y'
51
+ 10. Tag the release:
52
+ ` ` ` sh
53
+ git tag -a v{0.X.Y} -m ' v{0.X.Y}'
36
54
` ` `
37
- 7. Tag the release:
38
- ```
39
- git tag -a v0.X.Y -m 'v0.X.Y'
40
- ```
41
- 8. Build source and binary wheels for pypi:
42
- ```
43
- git clean -xdf # this deletes all uncommited changes!
55
+ 11. Build source and binary wheels for PyPI:
56
+ ` ` ` sh
57
+ git clean -xdf # this deletes all uncommitted changes!
44
58
python setup.py bdist_wheel sdist
45
59
` ` `
46
- 9 . Use twine to check the package build:
47
- ```
48
- twine check dist/xarray-0.X.Y*
60
+ 12 . Use twine to check the package build:
61
+ ` ` ` sh
62
+ twine check dist/xarray-{ 0.X.Y} *
49
63
` ` `
50
- 10 . Use twine to register and upload the release on pypi . Be careful, you can't
64
+ 13 . Use twine to register and upload the release on PyPI . Be careful, you can' t
51
65
take this back!
52
- ```
53
- twine upload dist/xarray-0.X.Y*
66
+ ```sh
67
+ twine upload dist/xarray-{ 0.X.Y} *
54
68
```
55
69
You will need to be listed as a package owner at
56
70
https://pypi.python.org/pypi/xarray for this to work.
57
- 11 . Push your changes to master:
58
- ```
71
+ 14 . Push your changes to master:
72
+ ```sh
59
73
git push upstream master
60
74
git push upstream --tags
61
75
```
62
- 12 . Update the stable branch (used by ReadTheDocs) and switch back to master:
63
- ```
76
+ 15 . Update the stable branch (used by ReadTheDocs) and switch back to master:
77
+ ```sh
64
78
git checkout stable
65
79
git rebase master
66
- git push upstream stable
80
+ git push --force upstream stable
67
81
git checkout master
68
82
```
69
83
It' s OK to force push to ' stable' if necessary. (We also update the stable
70
- branch with `git cherrypick ` for documentation only fixes that apply the
84
+ branch with ` git cherry-pick ` for documentation only fixes that apply the
71
85
current released version.)
72
- 13 . Add a section for the next release (v .X.Y+1) to doc/whats-new.rst:
86
+ 16 . Add a section for the next release {0 .X.Y+1} to doc/whats-new.rst:
73
87
` ` `
74
- .. _whats-new.0.X.Y+1:
88
+ .. _whats-new.{ 0.X.Y+1} :
75
89
76
- v0 .X.Y+1 (unreleased)
90
+ v{0 .X.Y+1} (unreleased)
77
91
---------------------
78
92
79
93
Breaking changes
@@ -95,20 +109,20 @@ Time required: about an hour.
95
109
Internal Changes
96
110
~ ~~~~~~~~~~~~~~~
97
111
` ` `
98
- 14 . Commit your changes and push to master again:
99
- ```
112
+ 17 . Commit your changes and push to master again:
113
+ ` ` ` sh
100
114
git commit -am ' New whatsnew section'
101
115
git push upstream master
102
116
` ` `
103
117
You' re done pushing to master!
104
- 15 . Issue the release on GitHub. Click on "Draft a new release" at
105
- https://github.com/pydata/xarray/releases. Type in the version number, but
106
- don't bother to describe it -- we maintain that on the docs instead .
107
- 16 . Update the docs. Login to https://readthedocs.org/projects/xray/versions/
118
+ 18 . Issue the release on GitHub. Click on "Draft a new release" at
119
+ https://github.com/pydata/xarray/releases. Type in the version number
120
+ and paste the release summary in the notes .
121
+ 19 . Update the docs. Login to https://readthedocs.org/projects/xray/versions/
108
122
and switch your new release tag (at the bottom) from "Inactive" to "Active".
109
123
It should now build automatically.
110
- 17 . Issue the release announcement! For bug fix releases, I usually only email
111
- [email protected] . For major/feature releases, I will email a broader
124
+ 20 . Issue the release announcement to mailing lists & Twitter. For bug fix releases, I
125
+ usually only email [email protected] . For major/feature releases, I will email a broader
112
126
list (no more than once every 3-6 months):
113
127
114
128
0 commit comments