@@ -25,7 +25,7 @@ All Releases
25
25
Testing
26
26
-------
27
27
28
- We use `travis-ci <https://travis-ci.org/matplotlib/matplotlib >`__ for
28
+ We use `Travis CI <https://travis-ci.org/matplotlib/matplotlib >`__ for
29
29
continuous integration. When preparing for a release, the final
30
30
tagged commit should be tested locally before it is uploaded::
31
31
@@ -34,7 +34,7 @@ tagged commit should be tested locally before it is uploaded::
34
34
35
35
In addition the following test should be run and manually inspected::
36
36
37
- python unit /memleak.py agg agg.pdf
37
+ python tools /memleak.py agg 1000 agg.pdf
38
38
39
39
40
40
In addition the following should be run and manually inspected, but
@@ -51,42 +51,65 @@ GitHub Stats
51
51
------------
52
52
53
53
54
- We automatically extract GitHub issue, PRs, and authors from GitHub via the API.
55
- copy the current :file: `github_stats.rst ` to :file: `github_stats_X.Y.Z.rst `.
54
+ We automatically extract GitHub issue, PRs, and authors from GitHub via the
55
+ API. Copy the current :file: `doc/users/github_stats.rst ` to
56
+ :file: `doc/users/prev_whats_new/github_stats_X.Y.Z.rst `, changing the link
57
+ target at the top of the file, and removing the "Previous GitHub Stats" section
58
+ at the end.
56
59
57
- To re-generate the updated ::
60
+ For example, when updating from v3.2.0 to v3.2.1 ::
58
61
59
- python tools/github_stats.py --since-tag v2.2.0 --milestone=v3.0 --project 'matplotlib/matplotlib' --links > doc/users/github_stats.rst
62
+ cp doc/users/github_stats.rst doc/users/prev_whats_new/github_stats_3.2.0.rst
63
+ $EDITOR doc/users/prev_whats_new/github_stats_3.2.0.rst
64
+ # Change contents as noted above.
65
+ git add doc/users/prev_whats_new/github_stats_3.2.0.rst
60
66
61
- Review and commit changes. Some issue/PR titles may not be valid rst (the most common issue is
62
- ``* `` which is interpreted as unclosed markup).
67
+ Then re-generate the updated stats::
63
68
64
- .. note
69
+ python tools/github_stats.py --since-tag v3.2.0 --milestone=v3.2.1 --project 'matplotlib/matplotlib' --links > doc/users/github_stats.rst
65
70
66
- Make sure you authenticate against the github API (either via
67
- keyring or via putting an oauth token in :file:`~/.ghoauth`). If you
68
- do not you will get blocked by github for going over the API rate
69
- limits.
71
+ Review and commit changes. Some issue/PR titles may not be valid reST (the
72
+ most common issue is ``* `` which is interpreted as unclosed markup).
73
+
74
+ .. note ::
75
+
76
+ Make sure you authenticate against the GitHub API. If you
77
+ do not you will get blocked by GitHub for going over the API rate
78
+ limits. You can authenticate in one of two ways:
79
+
80
+ * using the ``keyring `` package; ``pip install keyring `` and then when
81
+ running the stats script, you will be prompted for user name and password,
82
+ that will be stored in your system keyring, or,
83
+ * using a personal access token; generate a new token `on this GitHub page
84
+ <https://github.com/settings/tokens> `__ with the ``repo:public_repo ``
85
+ scope and place the token in :file: `~/.ghoauth `.
70
86
71
87
72
88
.. _release_chkdocs :
73
89
74
90
Update and Validate the Docs
75
91
----------------------------
76
92
77
- Merge the most recent 'doc' branch (``v3.0.2-doc ``) into the branch you
93
+ Merge ``*-doc `` branch
94
+ ^^^^^^^^^^^^^^^^^^^^^^
95
+
96
+ Merge the most recent 'doc' branch (e.g., ``v3.2.0-doc ``) into the branch you
78
97
are going to tag on and delete the doc branch on GitHub.
79
98
80
- Before tagging, update the "what's new" and "API changes" listings.
99
+ Update "What's New" and "API changes"
100
+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
101
+
102
+ Before tagging major and minor releases, the "what's new" and "API changes"
103
+ listings should be updated. This is not needed for micro releases.
81
104
82
- for the "what's new"
105
+ For the "what's new",
83
106
84
107
1. copy the current content to a file in :file: `doc/users/prev_whats_new `
85
108
2. merge all of the files in :file: `doc/users/next_whats_new/ ` into
86
109
:file: `doc/users/whats_new.rst ` and delete the individual files
87
110
3. comment out the next whats new glob at the top
88
111
89
- Similarly for the "API changes"
112
+ Similarly for the "API changes",
90
113
91
114
1. copy the current api changes to a file is :file: `doc/api/prev_api_changes `
92
115
2. merge all of the files in :file: `doc/api/next_api_changes/ ` into
@@ -95,13 +118,17 @@ Similarly for the "API changes"
95
118
96
119
In both cases step 3 will have to be un-done right after the release.
97
120
121
+ Verify that docs build
122
+ ^^^^^^^^^^^^^^^^^^^^^^
123
+
98
124
Finally, make sure that the docs build cleanly ::
99
125
100
126
make -Cdoc O=-j$(nproc) html latexpdf
101
127
102
- After the docs are built, check that all of the links, internal and external, are still
103
- valid. We use ``linkchecker `` for this, which has not been ported to python3 yet. You will
104
- need to create a python2 environment with ``requests==2.9.0 `` and linkchecker ::
128
+ After the docs are built, check that all of the links, internal and external,
129
+ are still valid. We use ``linkchecker `` for this, which has not been ported to
130
+ Python3 yet. You will need to create a Python2 environment with
131
+ ``requests==2.9.0 `` and linkchecker ::
105
132
106
133
conda create -p /tmp/lnkchk python=2 requests==2.9.0
107
134
source activate /tmp/lnkchk
@@ -110,8 +137,8 @@ need to create a python2 environment with ``requests==2.9.0`` and linkchecker ::
110
137
linkchecker index.html --check-extern
111
138
popd
112
139
113
- Address any issues which may arise. The internal links are checked on travis, this should only
114
- flag failed external links.
140
+ Address any issues which may arise. The internal links are checked on Circle
141
+ CI, this should only flag failed external links.
115
142
116
143
.. _release_tag :
117
144
@@ -128,21 +155,21 @@ message ::
128
155
129
156
git tag -a -s v2.0.0
130
157
131
- which will prompt you for your gpg key password and an annotation.
132
- For pre releases it is important to follow :pep: `440 ` so that the
133
- build artifacts will sort correctly in pypi. Finally, push the tag to GitHub ::
134
-
135
- git push -t DANGER v2.0.0
136
-
137
- Congratulations, the scariest part is done!
158
+ which will prompt you for your GPG key password and an annotation. For pre
159
+ releases it is important to follow :pep: `440 ` so that the build artifacts will
160
+ sort correctly in PyPI.
138
161
139
162
To prevent issues with any down-stream builders which download the
140
163
tarball from GitHub it is important to move all branches away from the commit
141
164
with the tag [# ]_::
142
165
143
166
git commit --allow-empty
144
- git push DANGER master
145
167
168
+ Finally, push the tag to GitHub::
169
+
170
+ git push DANGER master v2.0.0
171
+
172
+ Congratulations, the scariest part is done!
146
173
147
174
.. [# ] The tarball that is provided by GitHub is produced using `git
148
175
archive <https://git-scm.com/docs/git-archive> `__. We use
@@ -170,8 +197,8 @@ done for pre-releases)::
170
197
git branch v2.0.0-doc
171
198
git push DANGER v2.0.0-doc
172
199
173
- and if this is a major or minor release, also create a bug-fix branch (a
174
- micro release will be cut off of this branch)::
200
+ and if this is a major or minor release, also create a bug-fix branch (a micro
201
+ release will be cut from this branch)::
175
202
176
203
git branch v2.0.x
177
204
@@ -192,31 +219,33 @@ Via the `GitHub UI
192
219
pushed tag into a release. If this is a pre-release remember to mark
193
220
it as such.
194
221
195
- For final releases also get a DOI from `zenodo
196
- <https://zenodo.org/> `__ and edit :file: ` doc/citing.rst ` with DOI link
197
- and commit to the VER-doc branch and push to GitHub ::
222
+ For final releases, also get the DOI from `zenodo < https://zenodo.org/ >`__
223
+ (which will automatically produce one once the tag is pushed), add the DOI link
224
+ to :file: ` doc/citing.rst `, commit to the VER-doc branch and push to GitHub ::
198
225
199
226
git checkout v2.0.0-doc
200
- emacs doc/_templates /citing.html
227
+ $EDITOR doc/citing.html
201
228
git push DANGER v2.0.0-doc:v2.0.0-doc
202
229
203
230
.. _release_bld_bin :
204
231
205
232
Building binaries
206
233
-----------------
207
234
208
- We distribute mac, windows, and many linux wheels as well as a source
209
- tarball via pypi. Before uploading anything, contact the various
210
- builders. Mac and manylinux wheels are built on travis . You need to
211
- edit the :file: `.travis.yml ` file and push to the correct branch of
212
- `the build project
213
- <https://github.com/MacPython/matplotlib-wheels> `__. For new minor
214
- versions create a new branch, for bug-fixes continue to use the current
215
- release branch.
216
-
217
- The auto-tick bot should open a pull request into the `conda-forge
218
- feedstock <https://github.com/conda-forge/matplotlib-feedstock> `__.
219
- Review and merge (if you have the power to).
235
+ We distribute macOS, Windows, and many Linux wheels as well as a source tarball
236
+ via PyPI. Most builders should trigger automatically once the tag is pushed to
237
+ GitHub:
238
+
239
+ * Mac and manylinux wheels are built on Travis CI. Builds are triggered by the
240
+ GitHub Action defined in :file: `.github/workflows/wheels.yml `, and wheels
241
+ will be available at the site defined in the `matplotlib-wheels repo
242
+ <https://github.com/MacPython/matplotlib-wheels> `__.
243
+ * Windows wheels are built by Christoph Gohlke automatically and will be
244
+ `available at his site
245
+ <https://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib> `__ once built.
246
+ * The auto-tick bot should open a pull request into the `conda-forge feedstock
247
+ <https://github.com/conda-forge/matplotlib-feedstock> `__. Review and merge
248
+ (if you have the power to).
220
249
221
250
.. warning ::
222
251
@@ -231,7 +260,6 @@ If this is a final release the following downstream packagers should be contacte
231
260
- Gentoo
232
261
- Macports
233
262
- Homebrew
234
- - Christoph Gohlke
235
263
- Continuum
236
264
- Enthought
237
265
@@ -240,8 +268,8 @@ This can be done ahead of collecting all of the binaries and uploading to pypi.
240
268
241
269
.. _release_upload_bin :
242
270
243
- make distribution and upload to pypi / SF
244
- -----------------------------------------
271
+ Make distribution and upload to PyPI
272
+ ------------------------------------
245
273
246
274
Once you have collected all of the wheels (expect this to take about a
247
275
day), generate the tarball ::
@@ -284,13 +312,12 @@ The built documentation exists in the `matplotlib.github.com
284
312
<https://github.com/matplotlib/matplotlib.github.com/> `__ repository.
285
313
Pushing changes to master automatically updates the website.
286
314
287
- The documentation is organized by version. At the root of the tree is
288
- always the documentation for the latest stable release. Under that,
289
- there are directories containing the documentation for older versions.
290
- The documentation for current master are built on travis and push to
291
- the `devdocs <https://github.com/matplotlib/devdocs/ >`__ repository.
292
- These are available at `matplotlib.org/devdocs
293
- <https://matplotlib.org/devdocs> `__.
315
+ The documentation is organized by version. At the root of the tree is always
316
+ the documentation for the latest stable release. Under that, there are
317
+ directories containing the documentation for older versions. The documentation
318
+ for current master is built on Circle CI and pushed to the `devdocs
319
+ <https://github.com/matplotlib/devdocs/> `__ repository. These are available at
320
+ `matplotlib.org/devdocs <https://matplotlib.org/devdocs >`__.
294
321
295
322
Assuming you have this repository checked out in the same directory as
296
323
matplotlib ::
@@ -314,7 +341,7 @@ You will need to manually edit :file:`versions.html` to show the last
314
341
315
342
Congratulations you have now done the third scariest part!
316
343
317
- If you have access, clear the cloudflare caches.
344
+ If you have access, clear the Cloudflare caches.
318
345
319
346
It typically takes about 5-10 minutes for GitHub to process the push
320
347
and update the live web page (remember to clear your browser cache).
@@ -326,7 +353,7 @@ Announcing
326
353
The final step is to announce the release to the world. A short
327
354
version of the release notes along with acknowledgments should be sent to
328
355
329
- - matplotlib-user @python.org
356
+ - matplotlib-users @python.org
330
357
- matplotlib-devel@python.org
331
358
- matplotlib-announce@python.org
332
359
0 commit comments