Show More
@@ -1,221 +1,221 b'' | |||
|
1 | 1 | .. _release_process: |
|
2 | 2 | |
|
3 | 3 | ======================= |
|
4 | 4 | IPython release process |
|
5 | 5 | ======================= |
|
6 | 6 | |
|
7 | 7 | This document contains the process that is used to create an IPython release. |
|
8 | 8 | |
|
9 | 9 | Conveniently, the ``release`` script in the ``tools`` directory of the ``IPython`` |
|
10 | 10 | repository automates most of the release process. This document serves as a |
|
11 | 11 | handy reminder and checklist for the release manager. |
|
12 | 12 | |
|
13 | 13 | 1. Set Environment variables |
|
14 | 14 | ---------------------------- |
|
15 | 15 | |
|
16 | 16 | Set environment variables to document previous release tag, current |
|
17 | 17 | release milestone, current release version, and git tag. |
|
18 | 18 | |
|
19 | 19 | These variables may be used later to copy/paste as answers to the script |
|
20 | 20 | questions instead of typing the appropriate command when the time comes. These |
|
21 | 21 | variables are not used by the scripts directly; therefore, there is no need to |
|
22 | ``export`` the variables. Use the following in bash: | |
|
22 | ``export`` the variables. Use the following in bash:: | |
|
23 | 23 |
|
|
24 | 24 | PREV_RELEASE=4.2.1 |
|
25 | 25 |
MILESTONE=5.0 |
|
26 | 26 |
|
|
27 | 27 |
|
|
28 | 28 |
|
|
29 | 29 | |
|
30 | 30 | 2. Create GitHub stats and finish release note |
|
31 | 31 | ---------------------------------------------- |
|
32 | 32 | |
|
33 | 33 | .. note:: |
|
34 | 34 | |
|
35 | 35 | This step is optional if making a Beta or RC release. |
|
36 | 36 | |
|
37 | 37 | .. note:: |
|
38 | 38 | |
|
39 | 39 | Before generating the GitHub stats, verify that all closed issues and pull |
|
40 | 40 | requests have `appropriate milestones |
|
41 | 41 | <https://github.com/ipython/ipython/wiki/Dev%3A-GitHub-workflow#milestones>`_. |
|
42 | 42 | `This search |
|
43 | 43 | <https://github.com/ipython/ipython/issues?q=is%3Aclosed+no%3Amilestone+is%3Aissue>`_ |
|
44 | 44 | should return no results before creating the GitHub stats. |
|
45 | 45 | |
|
46 | 46 | If a major release: |
|
47 | 47 | |
|
48 | 48 | - merge any pull request notes into what's new:: |
|
49 | 49 | |
|
50 | 50 | python tools/update_whatsnew.py |
|
51 | 51 | |
|
52 | 52 | - update ``docs/source/whatsnew/development.rst``, to ensure it covers |
|
53 | 53 | the major release features |
|
54 | 54 | |
|
55 | 55 | - move the contents of ``development.rst`` to ``versionX.rst`` where ``X`` is |
|
56 | 56 | the numerical release version |
|
57 | 57 | |
|
58 | 58 | - generate summary of GitHub contributions, which can be done with:: |
|
59 | 59 | |
|
60 | 60 | python tools/github_stats.py --milestone $MILESTONE > stats.rst |
|
61 | 61 | |
|
62 | 62 | which may need some manual cleanup of ``stats.rst``. Add the cleaned |
|
63 | 63 | ``stats.rst`` results to ``docs/source/whatsnew/github-stats-X.rst`` |
|
64 | 64 | where ``X`` is the numerical release version. If creating a major release, |
|
65 | 65 | make a new ``github-stats-X.rst`` file; if creating a minor release, the |
|
66 | 66 | content from ``stats.rst`` may simply be added to the top of an existing |
|
67 | 67 | ``github-stats-X.rst`` file. |
|
68 | 68 | |
|
69 | 69 | To find duplicates and update `.mailmap`, use:: |
|
70 | 70 | |
|
71 | 71 | git log --format="%aN <%aE>" $PREV_RELEASE... | sort -u -f |
|
72 | 72 | |
|
73 | 73 | 3. Make sure the repository is clean |
|
74 | 74 | ------------------------------------ |
|
75 | 75 | |
|
76 | 76 | of any file that could be problematic. |
|
77 | 77 | Remove all non-tracked files with: |
|
78 | 78 | |
|
79 | 79 | .. code:: |
|
80 | 80 | |
|
81 | 81 | git clean -xfdi |
|
82 | 82 | |
|
83 | 83 | This will ask for confirmation before removing all untracked files. Make |
|
84 | 84 | sure the ``dist/`` folder is clean to avoid any stale builds from |
|
85 | 85 | previous build attempts. |
|
86 | 86 | |
|
87 | 87 | |
|
88 | 88 | 4. Update the release version number |
|
89 | 89 | ------------------------------------ |
|
90 | 90 | |
|
91 | 91 | Edit ``IPython/core/release.py`` to have the current version. |
|
92 | 92 | |
|
93 | 93 | in particular, update version number and ``_version_extra`` content in |
|
94 | 94 | ``IPython/core/release.py``. |
|
95 | 95 | |
|
96 | 96 | Step 5 will validate your changes automatically, but you might still want to |
|
97 | 97 | make sure the version number matches pep440. |
|
98 | 98 | |
|
99 | 99 | In particular, ``rc`` and ``beta`` are not separated by ``.`` or the ``sdist`` |
|
100 | 100 | and ``bdist`` will appear as different releases. For example, a valid version |
|
101 | 101 | number for a release candidate (rc) release is: ``1.3rc1``. Notice that there |
|
102 | 102 | is no separator between the '3' and the 'r'. Check the environment variable |
|
103 | 103 | ``$VERSION`` as well. |
|
104 | 104 | |
|
105 | 105 | You will likely just have to modify/comment/uncomment one of the lines setting |
|
106 | 106 | ``_version_extra`` |
|
107 | 107 | |
|
108 | 108 | |
|
109 | 109 | Comment remove the ``development`` entry in ``whatsnew/index.rst``. TODO, figure |
|
110 | 110 | out how to make that automatic. |
|
111 | 111 | |
|
112 | 112 | 5. Run the `tools/build_release` script |
|
113 | 113 | --------------------------------------- |
|
114 | 114 | |
|
115 | 115 | Running ``tools/build_release`` does all the file checking and building that |
|
116 | 116 | the real release script will do. This makes test installations, checks that |
|
117 | 117 | the build procedure runs OK, and tests other steps in the release process. |
|
118 | 118 | |
|
119 | 119 | The ``build_release`` script will in particular verify that the version number |
|
120 | 120 | match PEP 440, in order to avoid surprise at the time of build upload. |
|
121 | 121 | |
|
122 | 122 | We encourage creating a test build of the docs as well. |
|
123 | 123 | |
|
124 | 124 | 6. Create and push the new tag |
|
125 | 125 | ------------------------------ |
|
126 | 126 | |
|
127 | 127 | Commit the changes to release.py:: |
|
128 | 128 | |
|
129 | 129 | git commit -am "release $VERSION" |
|
130 | 130 | git push origin $BRANCH |
|
131 | 131 | |
|
132 | 132 | Create and push the tag:: |
|
133 | 133 | |
|
134 | 134 | git tag -am "release $VERSION" "$VERSION" |
|
135 | 135 | git push origin --tags |
|
136 | 136 | |
|
137 | 137 | Update release.py back to ``x.y-dev`` or ``x.y-maint``, and re-add the |
|
138 | 138 | ``development`` entry in ``docs/source/whatsnew/index.rst`` and push:: |
|
139 | 139 | |
|
140 | 140 | git commit -am "back to development" |
|
141 | 141 | git push origin $BRANCH |
|
142 | 142 | |
|
143 | 143 | 7. Get a fresh clone |
|
144 | 144 | -------------------- |
|
145 | 145 | |
|
146 | 146 | Get a fresh clone of the tag for building the release:: |
|
147 | 147 | |
|
148 | 148 | cd /tmp |
|
149 | 149 | git clone --depth 1 https://github.com/ipython/ipython.git -b "$VERSION" |
|
150 | 150 | cd ipython |
|
151 | 151 | |
|
152 | 152 | .. note:: |
|
153 | 153 | |
|
154 | 154 | You can aslo cleanup the current working repository with ``git clean -xfdi`` |
|
155 | 155 | |
|
156 | 156 | 8. Run the release script |
|
157 | 157 | ------------------------- |
|
158 | 158 | |
|
159 | 159 | Run the ``release`` script, this step requires having a current wheel, Python |
|
160 | 160 | >=3.4 and Python 2.7.:: |
|
161 | 161 | |
|
162 | 162 | ./tools/release |
|
163 | 163 | |
|
164 | 164 | This makes the tarballs, zipfiles, and wheels, and put them under the ``dist/`` |
|
165 | 165 | folder. Be sure to test the ``wheel`` and the ``sdist`` locally before uploading |
|
166 | 166 | them to PyPI. |
|
167 | 167 | |
|
168 | 168 | Use the following to actually upload the result of the build:: |
|
169 | 169 | |
|
170 | 170 | ./tools/release upload |
|
171 | 171 | |
|
172 | 172 | It should posts them to ``archive.ipython.org``. |
|
173 | 173 | |
|
174 | 174 | You will need to use `twine <https://github.com/pypa/twine>`_ (``twine upload |
|
175 | 175 | dist/*``) manually to actually upload on PyPI. Unlike setuptools, twine is able |
|
176 | 176 | to upload packages over SSL. |
|
177 | 177 | |
|
178 | 178 | |
|
179 | 179 | PyPI/Warehouse will automatically hide previous releases. If you are uploading |
|
180 | 180 | a non-stable version, make sure to log-in to PyPI and un-hide previous version. |
|
181 | 181 | |
|
182 | 182 | |
|
183 | 183 | 9. Draft a short release announcement |
|
184 | 184 | ------------------------------------- |
|
185 | 185 | |
|
186 | 186 | The announcement should include: |
|
187 | 187 | |
|
188 | 188 | - release highlights |
|
189 | 189 | - a link to the html version of the *What's new* section of the documentation |
|
190 | 190 | - a link to upgrade or installation tips (if necessary) |
|
191 | 191 | |
|
192 | 192 | Post the announcement to the mailing list and or blog, and link from Twitter. |
|
193 | 193 | |
|
194 | 194 | .. note:: |
|
195 | 195 | |
|
196 | 196 | If you are doing a RC or Beta, you can likely skip the next steps. |
|
197 | 197 | |
|
198 | 198 | 10. Update milestones on GitHub |
|
199 | 199 | ------------------------------- |
|
200 | 200 | |
|
201 | 201 | These steps will bring milestones up to date: |
|
202 | 202 | |
|
203 | 203 | - close the just released milestone |
|
204 | 204 | - open a new milestone for the next release (x, y+1), if the milestone doesn't |
|
205 | 205 | exist already |
|
206 | 206 | |
|
207 | 207 | 11. Update the IPython website |
|
208 | 208 | ------------------------------ |
|
209 | 209 | |
|
210 | 210 | The IPython website should document the new release: |
|
211 | 211 | |
|
212 | 212 | - add release announcement (news, announcements) |
|
213 | 213 | - update current version and download links |
|
214 | 214 | - update links on the documentation page (especially if a major release) |
|
215 | 215 | |
|
216 | 216 | 12. Celebrate! |
|
217 | 217 | -------------- |
|
218 | 218 | |
|
219 | 219 | Celebrate the release and please thank the contributors for their work. Great |
|
220 | 220 | job! |
|
221 | 221 |
General Comments 0
You need to be logged in to leave comments.
Login now