@@ -23,7 +23,7 @@ Time required: about an hour.
23
23
4. Check that the ReadTheDocs build is passing.
24
24
5. On the master branch, commit the release in git:
25
25
```
26
- git commit -a -m 'Release v0.X.Y'
26
+ git commit -am 'Release v0.X.Y'
27
27
```
28
28
6. Tag the release:
29
29
```
@@ -60,10 +60,35 @@ Time required: about an hour.
60
60
It's OK to force push to 'stable' if necessary. (We also update the stable
61
61
branch with `git cherrypick` for documentation only fixes that apply the
62
62
current released version.)
63
- 12. Add a section for the next release (v.X.(Y+1)) to doc/whats-new.rst.
63
+ 12. Add a section for the next release (v.X.Y+1) to doc/whats-new.rst:
64
+ ```
65
+ .. _whats-new.0.X.Y+1:
66
+
67
+ v0.X.Y+1 (unreleased)
68
+ ---------------------
69
+
70
+ Breaking changes
71
+ ~~~~~~~~~~~~~~~~
72
+
73
+
74
+ New Features
75
+ ~~~~~~~~~~~~
76
+
77
+
78
+ Bug fixes
79
+ ~~~~~~~~~
80
+
81
+
82
+ Documentation
83
+ ~~~~~~~~~~~~~
84
+
85
+
86
+ Internal Changes
87
+ ~~~~~~~~~~~~~~~~
88
+ ```
64
89
13. Commit your changes and push to master again:
65
90
```
66
- git commit -a -m 'New whatsnew section'
91
+ git commit -am 'New whatsnew section'
67
92
git push upstream master
68
93
```
69
94
You're done pushing to master!
@@ -88,15 +113,17 @@ Time required: about an hour.
88
113
```
89
114
git log "$(git tag --sort="v:refname" | sed -n 'x;$p').." --format="%aN" | sort -u
90
115
```
91
- or by replacing `v0.X.Y` with the _previous_ release in:
116
+ or by substituting the _previous_ release in:
92
117
```
93
- git log v0.X.Y.. --format="%aN" | sort -u
118
+ git log v0.X.Y-1 .. --format="%aN" | sort -u
94
119
```
120
+ NB: copying this output into a Google Groups form can cause
121
+ [issues](https://groups.google.com/forum/#!topic/xarray/hK158wAviPs) with line breaks, so take care
95
122
96
123
Note on version numbering:
97
124
98
125
We follow a rough approximation of semantic version. Only major releases (0.X.0)
99
- show include breaking changes. Minor releases (0.X.Y) are for bug fixes and
126
+ should include breaking changes. Minor releases (0.X.Y) are for bug fixes and
100
127
backwards compatible new features, but if a sufficient number of new features
101
128
have arrived we will issue a major release even if there are no compatibility
102
129
breaks.
0 commit comments