2
2
3
3
.. _release-guide :
4
4
5
- ===============
6
- Release Guide
7
- ===============
5
+ =============
6
+ Release Guide
7
+ =============
8
8
9
9
10
10
.. admonition :: This document is only relevant for Matplotlib release managers.
17
17
This assumes that a read-only remote for the canonical repository is
18
18
``remote `` and a read/write remote is ``DANGER ``
19
19
20
- All Releases
21
- ============
22
20
23
21
.. _release-testing :
24
22
25
23
Testing
26
- -------
24
+ =======
27
25
28
26
We use `Travis CI <https://travis-ci.org/matplotlib/matplotlib >`__ for
29
27
continuous integration. When preparing for a release, the final
@@ -48,7 +46,7 @@ is currently broken::
48
46
.. _release_ghstats :
49
47
50
48
GitHub Stats
51
- ------------
49
+ ============
52
50
53
51
54
52
We automatically extract GitHub issue, PRs, and authors from GitHub via the
@@ -88,23 +86,23 @@ most common issue is ``*`` which is interpreted as unclosed markup).
88
86
.. _release_chkdocs :
89
87
90
88
Update and Validate the Docs
91
- ----------------------------
89
+ ============================
92
90
93
91
Merge ``*-doc `` branch
94
- ^^^^^^^^^^^^^^^^^^^^^^
92
+ ----------------------
95
93
96
94
Merge the most recent 'doc' branch (e.g., ``v3.2.0-doc ``) into the branch you
97
95
are going to tag on and delete the doc branch on GitHub.
98
96
99
97
Update supported versions in Security Policy
100
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
98
+ --------------------------------------------
101
99
102
100
When making major or minor releases, update the supported versions in the
103
101
Security Policy in :file: `SECURITY.md `. Commonly, this may be one or two
104
102
previous minor releases, but is dependent on release managers.
105
103
106
104
Update "What's New" and "API changes"
107
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
105
+ -------------------------------------
108
106
109
107
Before tagging major and minor releases, the "what's new" and "API changes"
110
108
listings should be updated. This is not needed for micro releases.
@@ -126,7 +124,7 @@ Similarly for the "API changes",
126
124
In both cases step 3 will have to be un-done right after the release.
127
125
128
126
Verify that docs build
129
- ^^^^^^^^^^^^^^^^^^^^^^
127
+ ----------------------
130
128
131
129
Finally, make sure that the docs build cleanly ::
132
130
@@ -150,7 +148,7 @@ CI, this should only flag failed external links.
150
148
.. _release_tag :
151
149
152
150
Create release commit and tag
153
- -----------------------------
151
+ =============================
154
152
155
153
To create the tag, first create an empty commit with a very terse set of the release notes
156
154
in the commit message ::
@@ -219,7 +217,7 @@ On this branch un-comment the globs from :ref:`release_chkdocs`. And then ::
219
217
.. _release_DOI :
220
218
221
219
Release Management / DOI
222
- ------------------------
220
+ ========================
223
221
224
222
Via the `GitHub UI
225
223
<https://github.com/matplotlib/matplotlib/releases> `__, turn the newly
@@ -247,7 +245,7 @@ to :file:`tools/cache_zenodo_svg.py`, and the changes to
247
245
.. _release_bld_bin :
248
246
249
247
Building binaries
250
- -----------------
248
+ =================
251
249
252
250
We distribute macOS, Windows, and many Linux wheels as well as a source tarball
253
251
via PyPI. Most builders should trigger automatically once the tag is pushed to
@@ -286,7 +284,7 @@ This can be done ahead of collecting all of the binaries and uploading to pypi.
286
284
.. _release_upload_bin :
287
285
288
286
Make distribution and upload to PyPI
289
- ------------------------------------
287
+ ====================================
290
288
291
289
Once you have collected all of the wheels (expect this to take about a
292
290
day), generate the tarball ::
@@ -311,7 +309,7 @@ Congratulations, you have now done the second scariest part!
311
309
.. _release_docs :
312
310
313
311
Build and Deploy Documentation
314
- ------------------------------
312
+ ==============================
315
313
316
314
To build the documentation you must have the tagged version installed, but
317
315
build the docs from the ``ver-doc `` branch. An easy way to arrange this is::
@@ -365,7 +363,7 @@ and update the live web page (remember to clear your browser cache).
365
363
366
364
367
365
Announcing
368
- ----------
366
+ ==========
369
367
370
368
The final step is to announce the release to the world. A short
371
369
version of the release notes along with acknowledgments should be sent to
0 commit comments