Show More
@@ -0,0 +1,50 | |||
|
1 | .. old_release_doc:: | |
|
2 | ||
|
3 | Making an IPython release [TODO:: Can this be replaced by the Release Process document???] | |
|
4 | ========================================================================================== | |
|
5 | ||
|
6 | Make sure the repository is clean of any file that could be problematic. | |
|
7 | You can remove all non-tracked files with: | |
|
8 | ||
|
9 | .. code:: | |
|
10 | ||
|
11 | git clean -xfdi | |
|
12 | ||
|
13 | This would ask you for confirmation before removing all untracked files. Make | |
|
14 | sure the ``dist/`` folder is clean and avoid stale build from | |
|
15 | previous attempts. | |
|
16 | ||
|
17 | 1. Update version number in ``IPython/core/release.py``. | |
|
18 | ||
|
19 | Make sure the version number match pep440, in particular, `rc` and `beta` are | |
|
20 | not separated by `.` or the `sdist` and `bdist` will appear as different | |
|
21 | releases. | |
|
22 | ||
|
23 | 2. Commit and tag the release with the current version number: | |
|
24 | ||
|
25 | .. code:: | |
|
26 | ||
|
27 | git commit -am "release $VERSION" | |
|
28 | git tag $VERSION | |
|
29 | ||
|
30 | ||
|
31 | 3. You are now ready to build the ``sdist`` and ``wheel``: | |
|
32 | ||
|
33 | .. code:: | |
|
34 | ||
|
35 | python setup.py sdist --formats=zip,gztar | |
|
36 | python2 setup.py bdist_wheel | |
|
37 | python3 setup.py bdist_wheel | |
|
38 | ||
|
39 | ||
|
40 | 4. You can now test the ``wheel`` and the ``sdist`` locally before uploading to PyPI. | |
|
41 | Make sure to use `twine <https://github.com/pypa/twine>`_ to upload the archives over SSL. | |
|
42 | ||
|
43 | .. code:: | |
|
44 | ||
|
45 | $ twine upload dist/* | |
|
46 | ||
|
47 | 5. If all went well, change the ``IPython/core/release.py`` back adding the ``.dev`` suffix. | |
|
48 | ||
|
49 | 6. Push directly on master, not forgetting to push ``--tags``. | |
|
50 |
@@ -16,52 +16,4 on the IPython GitHub wiki. | |||
|
16 | 16 | :maxdepth: 1 |
|
17 | 17 | |
|
18 | 18 | release_process |
|
19 | ||
|
20 | Making an IPython release | |
|
21 | ========================= | |
|
22 | ||
|
23 | Make sure the repository is clean of any file that could be problematic. | |
|
24 | You can remove all non-tracked files with: | |
|
25 | ||
|
26 | .. code:: | |
|
27 | ||
|
28 | git clean -xfdi | |
|
29 | ||
|
30 | This would ask you for confirmation before removing all untracked files. Make | |
|
31 | sure the ``dist/`` folder is clean and avoid stale build from | |
|
32 | previous attempts. | |
|
33 | ||
|
34 | 1. Update version number in ``IPython/core/release.py``. | |
|
35 | ||
|
36 | Make sure the version number match pep440, in particular, `rc` and `beta` are | |
|
37 | not separated by `.` or the `sdist` and `bdist` will appear as different | |
|
38 | releases. | |
|
39 | ||
|
40 | 2. Commit and tag the release with the current version number: | |
|
41 | ||
|
42 | .. code:: | |
|
43 | ||
|
44 | git commit -am "release $VERSION" | |
|
45 | git tag $VERSION | |
|
46 | ||
|
47 | ||
|
48 | 3. You are now ready to build the ``sdist`` and ``wheel``: | |
|
49 | ||
|
50 | .. code:: | |
|
51 | ||
|
52 | python setup.py sdist --formats=zip,gztar | |
|
53 | python2 setup.py bdist_wheel | |
|
54 | python3 setup.py bdist_wheel | |
|
55 | ||
|
56 | ||
|
57 | 4. You can now test the ``wheel`` and the ``sdist`` locally before uploading to PyPI. | |
|
58 | Make sure to use `twine <https://github.com/pypa/twine>`_ to upload the archives over SSL. | |
|
59 | ||
|
60 | .. code:: | |
|
61 | ||
|
62 | $ twine upload dist/* | |
|
63 | ||
|
64 | 5. If all went well, change the ``IPython/core/release.py`` back adding the ``.dev`` suffix. | |
|
65 | ||
|
66 | 6. Push directly on master, not forgetting to push ``--tags``. | |
|
67 | ||
|
19 | old_release_doc |
@@ -1,13 +1,20 | |||
|
1 | This document contains notes about the process that is used to release IPython. | |
|
2 | Our release process is currently not very formal and could be improved. | |
|
1 | .. _release_process: | |
|
3 | 2 | |
|
4 | Most of the release process is automated by the `release` script in the `tools` | |
|
5 | directory of our main repository. This document is just a handy reminder for | |
|
6 | the release manager. | |
|
3 | ====================== | |
|
4 | Releasing core IPython | |
|
5 | ====================== | |
|
7 | 6 | |
|
8 | # 0. Environment variables | |
|
7 | This document contains the process that is used to create an IPython release. | |
|
9 | 8 | |
|
10 | You can set some env variables to note previous release tag and current release milestone, version, and git tag: | |
|
9 | Conveniently, the `release` script in the `tools` directory of the `IPython` | |
|
10 | repository automates most of the release process. This document serves as a | |
|
11 | handy reminder and checklist for the release manager. | |
|
12 | ||
|
13 | #. Set Environment variables | |
|
14 | ---------------------------- | |
|
15 | ||
|
16 | Set environment variables to document previous release tag, current | |
|
17 | release milestone, current release version, and git tag: | |
|
11 | 18 | |
|
12 | 19 | PREV_RELEASE=rel-1.0.0 |
|
13 | 20 | MILESTONE=1.1 |
@@ -15,37 +22,58 You can set some env variables to note previous release tag and current release | |||
|
15 | 22 | TAG="rel-$VERSION" |
|
16 | 23 | BRANCH=master |
|
17 | 24 | |
|
18 | These will be used later if you want to copy/paste, or you can just type the appropriate command when the time comes. These variables are not used by scripts (hence no `export`). | |
|
25 | These variables may be used later to copy/paste as answers to the script | |
|
26 | questions instead of typing the appropriate command when the time comes. These | |
|
27 | variables are not used by the scripts directly; therefore, there is no need to | |
|
28 | `export` the variables. | |
|
29 | ||
|
30 | #. Finish release notes | |
|
31 | ----------------------- | |
|
32 | ||
|
33 | .. note:: | |
|
19 | 34 | |
|
20 | # 1. Finish release notes | |
|
35 | Before generating the GitHub stats, verify that all closed issues and | |
|
36 | pull requests `have appropriate milestones <https://github.com/ipython/ipython/wiki/Dev%3A-GitHub-workflow#milestones>`_. | |
|
37 | `This search <https://github.com/ipython/ipython/issues?q=is%3Aclosed+no%3Amilestone+is%3Aissue>`_ | |
|
38 | should return no results before creating the GitHub stats. | |
|
21 | 39 | |
|
22 |
|
|
|
40 | If a major release: | |
|
23 | 41 | |
|
24 | - merge any pull request notes into what's new: | |
|
42 | - merge any pull request notes into what's new:: | |
|
25 | 43 | |
|
26 | 44 | python tools/update_whatsnew.py |
|
27 | 45 | |
|
28 |
- update `docs/source/whatsnew/development.rst`, to ensure it covers |
|
|
29 | - move the contents of `development.rst` to `versionX.rst` | |
|
30 | - generate summary of GitHub contributions, which can be done with: | |
|
46 | - update `docs/source/whatsnew/development.rst`, to ensure it covers | |
|
47 | the major release features | |
|
48 | - move the contents of `development.rst` to `versionX.rst` where `X` is | |
|
49 | the numerical release version | |
|
50 | - generate summary of GitHub contributions, which can be done with:: | |
|
31 | 51 | |
|
32 | python tools/github_stats.py --milestone $MILESTONE > stats.rst | |
|
52 | python tools/github_stats.py --milestone $MILESTONE > stats.rst | |
|
33 | 53 | |
|
34 | which may need some manual cleanup. Add the cleaned up result and add it to `docs/source/whatsnew/github-stats-X.rst` (make a new file, or add it to the top, depending on whether it is a major release). | |
|
35 | You can use: | |
|
54 | which may need some manual cleanup of `stats.rst`. Add the cleaned | |
|
55 | `stats.rst` results to `docs/source/whatsnew/github-stats-X.rst` where | |
|
56 | `X` is the numerical release version. If creating a major release, make | |
|
57 | a new `github-stats-X.rst` file; if creating a minor release, the | |
|
58 | content from `stats.rst` may simply be added to the top of an existing | |
|
59 | `github-stats-X.rst` file. | |
|
36 | 60 | |
|
37 | git log --format="%aN <%aE>" $PREV_RELEASE... | sort -u -f | |
|
61 | To find duplicates and update `.mailmap`, use: | |
|
38 | 62 | |
|
39 | to find duplicates and update `.mailmap`. | |
|
40 | Before generating the GitHub stats, verify that all closed issues and pull requests [have appropriate milestones](https://github.com/ipython/ipython/wiki/Dev%3A-GitHub-workflow#milestones). [This search](https://github.com/ipython/ipython/issues?q=is%3Aclosed+no%3Amilestone+is%3Aissue) should return no results. | |
|
63 | git log --format="%aN <%aE>" $PREV_RELEASE... | sort -u -f | |
|
41 | 64 | |
|
42 | # 2. Run the `tools/build_release` script | |
|
43 | 65 |
|
|
44 | This does all the file checking and building that the real release script will do. | |
|
45 | This will let you do test installations, check that the build procedure runs OK, etc. | |
|
46 | You may want to also do a test build of the docs. | |
|
66 | #. Run the `tools/build_release` script | |
|
67 | --------------------------------------- | |
|
47 | 68 | |
|
48 | # 3. Create and push the new tag | |
|
69 | This does all the file checking and building that the real release script will | |
|
70 | do. This makes test installations, checks that the build procedure runs OK, | |
|
71 | and tests other steps in the release process. | |
|
72 | ||
|
73 | We encourage creating a test build of the docs as well. | |
|
74 | ||
|
75 | #. Create and push the new tag | |
|
76 | ------------------------------ | |
|
49 | 77 | |
|
50 | 78 | Edit `IPython/core/release.py` to have the current version. |
|
51 | 79 | |
@@ -64,36 +92,51 Update release.py back to `x.y-dev` or `x.y-maint`, and push: | |||
|
64 | 92 | git commit -am "back to development" |
|
65 | 93 | git push origin $BRANCH |
|
66 | 94 | |
|
67 | # 4. Get a fresh clone of the tag for building the release: | |
|
95 | #. Get a fresh clone | |
|
96 | -------------------- | |
|
68 | 97 | |
|
69 | cd /tmp | |
|
70 | git clone --depth 1 https://github.com/ipython/ipython.git -b "$TAG" | |
|
98 | Get a fresh clone of the tag for building the release: | |
|
71 | 99 | |
|
72 | # 5. Run the `release` script | |
|
100 | cd /tmp | |
|
101 | git clone --depth 1 https://github.com/ipython/ipython.git -b "$TAG" | |
|
73 | 102 | |
|
74 | cd tools && ./release | |
|
103 | #. Run the release script | |
|
104 | ------------------------- | |
|
75 | 105 | |
|
76 | This makes the tarballs, zipfiles, and wheels. It posts them to archive.ipython.org and | |
|
77 | registers the release with PyPI. | |
|
106 | Run the `release` script:: | |
|
78 | 107 |
|
|
79 | This will require that you have current wheel, Python 3.4 and Python 2.7. | |
|
108 | cd tools && ./release | |
|
80 | 109 | |
|
81 | # 7. Update the IPython website | |
|
110 | This makes the tarballs, zipfiles, and wheels. It posts | |
|
111 | them to archive.ipython.org and registers the release with PyPI. | |
|
82 | 112 | |
|
83 | - release announcement (news, announcements) | |
|
84 | - update current version and download links | |
|
85 | - (If major release) update links on the documentation page | |
|
113 | This step requires having a current wheel, Python 3.4 and Python 2.7. | |
|
86 | 114 | |
|
87 |
# |
|
|
115 | #. Draft a short release announcement | |
|
116 | ------------------------------------- | |
|
88 | 117 | |
|
89 | 118 | This should include i) highlights and ii) a link to the html version of |
|
90 | 119 | the *What's new* section of the documentation. |
|
91 | 120 | |
|
92 | Post to mailing list, and link from Twitter. | |
|
121 | Post the announcement to the mailing list, and link from Twitter. | |
|
122 | ||
|
123 | #. Update milestones on GitHub | |
|
124 | ------------------------------ | |
|
125 | ||
|
126 | - close the just released milestone | |
|
127 | - open a new milestone for the next release (x, y+1), if the milestone doesn't | |
|
128 | exist already | |
|
129 | ||
|
130 | #. Update the IPython website | |
|
131 | ----------------------------- | |
|
132 | The IPython website should document the new release: | |
|
133 | ||
|
134 | - add release announcement (news, announcements) | |
|
135 | - update current version and download links | |
|
136 | - update links on the documentation page (especially if a major release) | |
|
93 | 137 | |
|
94 | # 9. Update milestones on GitHub | |
|
138 | #. Celebrate! | |
|
139 | ------------- | |
|
95 | 140 | |
|
96 | - close the milestone you just released | |
|
97 | - open new milestone for (x, y+1), if it doesn't exist already | |
|
141 | Celebrate the release and thank the contributors for their work. | |
|
98 | 142 | |
|
99 | # 10. Celebrate! |
@@ -5,9 +5,9 Developer's guide for Third Party Tools and Libraries | |||
|
5 | 5 | ===================================================== |
|
6 | 6 | |
|
7 | 7 | .. important: |
|
8 | ||
|
8 | ||
|
9 | 9 | This guide contains information for developers of third party tools and |
|
10 |
libraries that use IPython. Documentation for developers of co |
|
|
10 | libraries that use IPython. Documentation for developers of co | |
|
11 | 11 | *IPython itself* can be found in the :doc:`coredev/index`. |
|
12 | 12 | |
|
13 | 13 | .. toctree:: |
@@ -24,7 +24,7 Developer's guide for Third Party Tools and Libraries | |||
|
24 | 24 | Making an IPython release |
|
25 | 25 | ========================= |
|
26 | 26 | |
|
27 |
Make sure the repository is clean of any file that could be problematic. |
|
|
27 | Make sure the repository is clean of any file that could be problematic. | |
|
28 | 28 | You can remove all non-tracked files with: |
|
29 | 29 | |
|
30 | 30 | .. code:: |
General Comments 0
You need to be logged in to leave comments.
Login now