Show More
@@ -1,119 +1,119 b'' | |||||
1 | # -*- coding: utf-8 -*- |
|
1 | # -*- coding: utf-8 -*- | |
2 | """Release data for the IPython project.""" |
|
2 | """Release data for the IPython project.""" | |
3 |
|
3 | |||
4 | #----------------------------------------------------------------------------- |
|
4 | #----------------------------------------------------------------------------- | |
5 | # Copyright (c) 2008, IPython Development Team. |
|
5 | # Copyright (c) 2008, IPython Development Team. | |
6 | # Copyright (c) 2001, Fernando Perez <fernando.perez@colorado.edu> |
|
6 | # Copyright (c) 2001, Fernando Perez <fernando.perez@colorado.edu> | |
7 | # Copyright (c) 2001, Janko Hauser <jhauser@zscout.de> |
|
7 | # Copyright (c) 2001, Janko Hauser <jhauser@zscout.de> | |
8 | # Copyright (c) 2001, Nathaniel Gray <n8gray@caltech.edu> |
|
8 | # Copyright (c) 2001, Nathaniel Gray <n8gray@caltech.edu> | |
9 | # |
|
9 | # | |
10 | # Distributed under the terms of the Modified BSD License. |
|
10 | # Distributed under the terms of the Modified BSD License. | |
11 | # |
|
11 | # | |
12 | # The full license is in the file COPYING.txt, distributed with this software. |
|
12 | # The full license is in the file COPYING.txt, distributed with this software. | |
13 | #----------------------------------------------------------------------------- |
|
13 | #----------------------------------------------------------------------------- | |
14 |
|
14 | |||
15 | # Name of the package for release purposes. This is the name which labels |
|
15 | # Name of the package for release purposes. This is the name which labels | |
16 | # the tarballs and RPMs made by distutils, so it's best to lowercase it. |
|
16 | # the tarballs and RPMs made by distutils, so it's best to lowercase it. | |
17 | name = 'ipython' |
|
17 | name = 'ipython' | |
18 |
|
18 | |||
19 | # IPython version information. An empty _version_extra corresponds to a full |
|
19 | # IPython version information. An empty _version_extra corresponds to a full | |
20 | # release. 'dev' as a _version_extra string means this is a development |
|
20 | # release. 'dev' as a _version_extra string means this is a development | |
21 | # version |
|
21 | # version | |
22 | _version_major = 7 |
|
22 | _version_major = 7 | |
23 | _version_minor = 0 |
|
23 | _version_minor = 0 | |
24 | _version_patch = 0 |
|
24 | _version_patch = 0 | |
25 | _version_extra = '.dev' |
|
25 | _version_extra = '.dev' | |
26 |
|
|
26 | _version_extra = 'b1' | |
27 | # _version_extra = '' # Uncomment this for full releases |
|
27 | # _version_extra = '' # Uncomment this for full releases | |
28 |
|
28 | |||
29 | # Construct full version string from these. |
|
29 | # Construct full version string from these. | |
30 | _ver = [_version_major, _version_minor, _version_patch] |
|
30 | _ver = [_version_major, _version_minor, _version_patch] | |
31 |
|
31 | |||
32 | __version__ = '.'.join(map(str, _ver)) |
|
32 | __version__ = '.'.join(map(str, _ver)) | |
33 | if _version_extra: |
|
33 | if _version_extra: | |
34 | __version__ = __version__ + _version_extra |
|
34 | __version__ = __version__ + _version_extra | |
35 |
|
35 | |||
36 | version = __version__ # backwards compatibility name |
|
36 | version = __version__ # backwards compatibility name | |
37 | version_info = (_version_major, _version_minor, _version_patch, _version_extra) |
|
37 | version_info = (_version_major, _version_minor, _version_patch, _version_extra) | |
38 |
|
38 | |||
39 | # Change this when incrementing the kernel protocol version |
|
39 | # Change this when incrementing the kernel protocol version | |
40 | kernel_protocol_version_info = (5, 0) |
|
40 | kernel_protocol_version_info = (5, 0) | |
41 | kernel_protocol_version = "%i.%i" % kernel_protocol_version_info |
|
41 | kernel_protocol_version = "%i.%i" % kernel_protocol_version_info | |
42 |
|
42 | |||
43 | description = "IPython: Productive Interactive Computing" |
|
43 | description = "IPython: Productive Interactive Computing" | |
44 |
|
44 | |||
45 | long_description = \ |
|
45 | long_description = \ | |
46 | """ |
|
46 | """ | |
47 | IPython provides a rich toolkit to help you make the most out of using Python |
|
47 | IPython provides a rich toolkit to help you make the most out of using Python | |
48 | interactively. Its main components are: |
|
48 | interactively. Its main components are: | |
49 |
|
49 | |||
50 | * A powerful interactive Python shell |
|
50 | * A powerful interactive Python shell | |
51 | * A `Jupyter <https://jupyter.org/>`_ kernel to work with Python code in Jupyter |
|
51 | * A `Jupyter <https://jupyter.org/>`_ kernel to work with Python code in Jupyter | |
52 | notebooks and other interactive frontends. |
|
52 | notebooks and other interactive frontends. | |
53 |
|
53 | |||
54 | The enhanced interactive Python shells have the following main features: |
|
54 | The enhanced interactive Python shells have the following main features: | |
55 |
|
55 | |||
56 | * Comprehensive object introspection. |
|
56 | * Comprehensive object introspection. | |
57 |
|
57 | |||
58 | * Input history, persistent across sessions. |
|
58 | * Input history, persistent across sessions. | |
59 |
|
59 | |||
60 | * Caching of output results during a session with automatically generated |
|
60 | * Caching of output results during a session with automatically generated | |
61 | references. |
|
61 | references. | |
62 |
|
62 | |||
63 | * Extensible tab completion, with support by default for completion of python |
|
63 | * Extensible tab completion, with support by default for completion of python | |
64 | variables and keywords, filenames and function keywords. |
|
64 | variables and keywords, filenames and function keywords. | |
65 |
|
65 | |||
66 | * Extensible system of 'magic' commands for controlling the environment and |
|
66 | * Extensible system of 'magic' commands for controlling the environment and | |
67 | performing many tasks related either to IPython or the operating system. |
|
67 | performing many tasks related either to IPython or the operating system. | |
68 |
|
68 | |||
69 | * A rich configuration system with easy switching between different setups |
|
69 | * A rich configuration system with easy switching between different setups | |
70 | (simpler than changing $PYTHONSTARTUP environment variables every time). |
|
70 | (simpler than changing $PYTHONSTARTUP environment variables every time). | |
71 |
|
71 | |||
72 | * Session logging and reloading. |
|
72 | * Session logging and reloading. | |
73 |
|
73 | |||
74 | * Extensible syntax processing for special purpose situations. |
|
74 | * Extensible syntax processing for special purpose situations. | |
75 |
|
75 | |||
76 | * Access to the system shell with user-extensible alias system. |
|
76 | * Access to the system shell with user-extensible alias system. | |
77 |
|
77 | |||
78 | * Easily embeddable in other Python programs and GUIs. |
|
78 | * Easily embeddable in other Python programs and GUIs. | |
79 |
|
79 | |||
80 | * Integrated access to the pdb debugger and the Python profiler. |
|
80 | * Integrated access to the pdb debugger and the Python profiler. | |
81 |
|
81 | |||
82 | The latest development version is always available from IPython's `GitHub |
|
82 | The latest development version is always available from IPython's `GitHub | |
83 | site <http://github.com/ipython>`_. |
|
83 | site <http://github.com/ipython>`_. | |
84 | """ |
|
84 | """ | |
85 |
|
85 | |||
86 | license = 'BSD' |
|
86 | license = 'BSD' | |
87 |
|
87 | |||
88 | authors = {'Fernando' : ('Fernando Perez','fperez.net@gmail.com'), |
|
88 | authors = {'Fernando' : ('Fernando Perez','fperez.net@gmail.com'), | |
89 | 'Janko' : ('Janko Hauser','jhauser@zscout.de'), |
|
89 | 'Janko' : ('Janko Hauser','jhauser@zscout.de'), | |
90 | 'Nathan' : ('Nathaniel Gray','n8gray@caltech.edu'), |
|
90 | 'Nathan' : ('Nathaniel Gray','n8gray@caltech.edu'), | |
91 | 'Ville' : ('Ville Vainio','vivainio@gmail.com'), |
|
91 | 'Ville' : ('Ville Vainio','vivainio@gmail.com'), | |
92 | 'Brian' : ('Brian E Granger', 'ellisonbg@gmail.com'), |
|
92 | 'Brian' : ('Brian E Granger', 'ellisonbg@gmail.com'), | |
93 | 'Min' : ('Min Ragan-Kelley', 'benjaminrk@gmail.com'), |
|
93 | 'Min' : ('Min Ragan-Kelley', 'benjaminrk@gmail.com'), | |
94 | 'Thomas' : ('Thomas A. Kluyver', 'takowl@gmail.com'), |
|
94 | 'Thomas' : ('Thomas A. Kluyver', 'takowl@gmail.com'), | |
95 | 'Jorgen' : ('Jorgen Stenarson', 'jorgen.stenarson@bostream.nu'), |
|
95 | 'Jorgen' : ('Jorgen Stenarson', 'jorgen.stenarson@bostream.nu'), | |
96 | 'Matthias' : ('Matthias Bussonnier', 'bussonniermatthias@gmail.com'), |
|
96 | 'Matthias' : ('Matthias Bussonnier', 'bussonniermatthias@gmail.com'), | |
97 | } |
|
97 | } | |
98 |
|
98 | |||
99 | author = 'The IPython Development Team' |
|
99 | author = 'The IPython Development Team' | |
100 |
|
100 | |||
101 | author_email = 'ipython-dev@python.org' |
|
101 | author_email = 'ipython-dev@python.org' | |
102 |
|
102 | |||
103 | url = 'https://ipython.org' |
|
103 | url = 'https://ipython.org' | |
104 |
|
104 | |||
105 |
|
105 | |||
106 | platforms = ['Linux','Mac OSX','Windows'] |
|
106 | platforms = ['Linux','Mac OSX','Windows'] | |
107 |
|
107 | |||
108 | keywords = ['Interactive','Interpreter','Shell', 'Embedding'] |
|
108 | keywords = ['Interactive','Interpreter','Shell', 'Embedding'] | |
109 |
|
109 | |||
110 | classifiers = [ |
|
110 | classifiers = [ | |
111 | 'Framework :: IPython', |
|
111 | 'Framework :: IPython', | |
112 | 'Intended Audience :: Developers', |
|
112 | 'Intended Audience :: Developers', | |
113 | 'Intended Audience :: Science/Research', |
|
113 | 'Intended Audience :: Science/Research', | |
114 | 'License :: OSI Approved :: BSD License', |
|
114 | 'License :: OSI Approved :: BSD License', | |
115 | 'Programming Language :: Python', |
|
115 | 'Programming Language :: Python', | |
116 | 'Programming Language :: Python :: 3', |
|
116 | 'Programming Language :: Python :: 3', | |
117 | 'Programming Language :: Python :: 3 :: Only', |
|
117 | 'Programming Language :: Python :: 3 :: Only', | |
118 | 'Topic :: System :: Shells' |
|
118 | 'Topic :: System :: Shells' | |
119 | ] |
|
119 | ] |
@@ -1,322 +1,322 b'' | |||||
1 | .. _core_developer_guide: |
|
1 | .. _core_developer_guide: | |
2 |
|
2 | |||
3 | ================================= |
|
3 | ================================= | |
4 | Guide for IPython core Developers |
|
4 | Guide for IPython core Developers | |
5 | ================================= |
|
5 | ================================= | |
6 |
|
6 | |||
7 | This guide documents the development of IPython itself. Alternatively, |
|
7 | This guide documents the development of IPython itself. Alternatively, | |
8 | developers of third party tools and libraries that use IPython should see the |
|
8 | developers of third party tools and libraries that use IPython should see the | |
9 | :doc:`../development/index`. |
|
9 | :doc:`../development/index`. | |
10 |
|
10 | |||
11 |
|
11 | |||
12 | For instructions on how to make a developer install see :ref:`devinstall`. |
|
12 | For instructions on how to make a developer install see :ref:`devinstall`. | |
13 |
|
13 | |||
14 | Backporting Pull requests |
|
14 | Backporting Pull requests | |
15 | ------------------------- |
|
15 | ------------------------- | |
16 |
|
16 | |||
17 | All pull requests should usually be made against ``master``, if a Pull Request |
|
17 | All pull requests should usually be made against ``master``, if a Pull Request | |
18 | need to be backported to an earlier release; then it should be tagged with the |
|
18 | need to be backported to an earlier release; then it should be tagged with the | |
19 | correct ``milestone``. |
|
19 | correct ``milestone``. | |
20 |
|
20 | |||
21 | If you tag a pull request with a milestone **before** merging the pull request, |
|
21 | If you tag a pull request with a milestone **before** merging the pull request, | |
22 | and the base ref is ``master``, then our backport bot should automatically create |
|
22 | and the base ref is ``master``, then our backport bot should automatically create | |
23 | a corresponding pull-request that backport on the correct branch. |
|
23 | a corresponding pull-request that backport on the correct branch. | |
24 |
|
24 | |||
25 | If you have write access to the IPython repository you can also just mention the |
|
25 | If you have write access to the IPython repository you can also just mention the | |
26 | **backport bot** to do the work for you. The bot is evolving so instructions may |
|
26 | **backport bot** to do the work for you. The bot is evolving so instructions may | |
27 | be different. At the time of this writing you can use:: |
|
27 | be different. At the time of this writing you can use:: | |
28 |
|
28 | |||
29 | @meeseeksdev[bot] backport [to] <branchname> |
|
29 | @meeseeksdev[bot] backport [to] <branchname> | |
30 |
|
30 | |||
31 | The bot will attempt to backport the current pull-request and issue a PR if |
|
31 | The bot will attempt to backport the current pull-request and issue a PR if | |
32 | possible. |
|
32 | possible. | |
33 |
|
33 | |||
34 | .. note:: |
|
34 | .. note:: | |
35 |
|
35 | |||
36 | The ``@`` and ``[bot]`` when mentioning the bot should be optional and can |
|
36 | The ``@`` and ``[bot]`` when mentioning the bot should be optional and can | |
37 | be omitted. |
|
37 | be omitted. | |
38 |
|
38 | |||
39 | If the pull request cannot be automatically backported, the bot should tell you |
|
39 | If the pull request cannot be automatically backported, the bot should tell you | |
40 | so on the PR and apply a "Need manual backport" tag to the origin PR. |
|
40 | so on the PR and apply a "Need manual backport" tag to the origin PR. | |
41 |
|
41 | |||
42 |
|
42 | |||
43 | Backport with ghpro |
|
43 | Backport with ghpro | |
44 | ------------------- |
|
44 | ------------------- | |
45 |
|
45 | |||
46 | We can also use `ghpro <https://pypi.python.org/pypi/ghpro>`_ |
|
46 | We can also use `ghpro <https://pypi.python.org/pypi/ghpro>`_ | |
47 | to automatically list and apply the PR on other branches. For example: |
|
47 | to automatically list and apply the PR on other branches. For example: | |
48 |
|
48 | |||
49 | .. code-block:: bash |
|
49 | .. code-block:: bash | |
50 |
|
50 | |||
51 | $ backport-pr todo --milestone 5.2 |
|
51 | $ backport-pr todo --milestone 5.2 | |
52 | [...snip..] |
|
52 | [...snip..] | |
53 | The following PRs have been backported |
|
53 | The following PRs have been backported | |
54 | 9848 |
|
54 | 9848 | |
55 | 9851 |
|
55 | 9851 | |
56 | 9953 |
|
56 | 9953 | |
57 | 9955 |
|
57 | 9955 | |
58 | The following PRs should be backported: |
|
58 | The following PRs should be backported: | |
59 | 9417 |
|
59 | 9417 | |
60 | 9863 |
|
60 | 9863 | |
61 | 9925 |
|
61 | 9925 | |
62 | 9947 |
|
62 | 9947 | |
63 |
|
63 | |||
64 | $ backport-pr apply 5.x 9947 |
|
64 | $ backport-pr apply 5.x 9947 | |
65 | [...snip...] |
|
65 | [...snip...] | |
66 |
|
66 | |||
67 |
|
67 | |||
68 | .. _release_process: |
|
68 | .. _release_process: | |
69 |
|
69 | |||
70 | ======================= |
|
70 | ======================= | |
71 | IPython release process |
|
71 | IPython release process | |
72 | ======================= |
|
72 | ======================= | |
73 |
|
73 | |||
74 | This document contains the process that is used to create an IPython release. |
|
74 | This document contains the process that is used to create an IPython release. | |
75 |
|
75 | |||
76 | Conveniently, the ``release`` script in the ``tools`` directory of the ``IPython`` |
|
76 | Conveniently, the ``release`` script in the ``tools`` directory of the ``IPython`` | |
77 | repository automates most of the release process. This document serves as a |
|
77 | repository automates most of the release process. This document serves as a | |
78 | handy reminder and checklist for the release manager. |
|
78 | handy reminder and checklist for the release manager. | |
79 |
|
79 | |||
80 | During the release process, you might need the extra following dependencies: |
|
80 | During the release process, you might need the extra following dependencies: | |
81 |
|
81 | |||
82 | - ``keyring`` to access your GitHub authentication tokens |
|
82 | - ``keyring`` to access your GitHub authentication tokens | |
83 | - ``graphviz`` to generate some graphs in the documentation |
|
83 | - ``graphviz`` to generate some graphs in the documentation | |
84 | - ``ghpro`` to generate the stats |
|
84 | - ``ghpro`` to generate the stats | |
85 |
|
85 | |||
86 | Make sure you have all the required dependencies to run the tests as well. |
|
86 | Make sure you have all the required dependencies to run the tests as well. | |
87 |
|
87 | |||
88 |
|
88 | |||
89 | 1. Set Environment variables |
|
89 | 1. Set Environment variables | |
90 | ---------------------------- |
|
90 | ---------------------------- | |
91 |
|
91 | |||
92 | Set environment variables to document previous release tag, current |
|
92 | Set environment variables to document previous release tag, current | |
93 | release milestone, current release version, and git tag. |
|
93 | release milestone, current release version, and git tag. | |
94 |
|
94 | |||
95 | These variables may be used later to copy/paste as answers to the script |
|
95 | These variables may be used later to copy/paste as answers to the script | |
96 | questions instead of typing the appropriate command when the time comes. These |
|
96 | questions instead of typing the appropriate command when the time comes. These | |
97 | variables are not used by the scripts directly; therefore, there is no need to |
|
97 | variables are not used by the scripts directly; therefore, there is no need to | |
98 | ``export`` them. The format for bash is as follows, but note that these values |
|
98 | ``export`` them. The format for bash is as follows, but note that these values | |
99 | are just an example valid only for the 5.0 release; you'll need to update them |
|
99 | are just an example valid only for the 5.0 release; you'll need to update them | |
100 | for the release you are actually making:: |
|
100 | for the release you are actually making:: | |
101 |
|
101 | |||
102 | PREV_RELEASE=4.2.1 |
|
102 | PREV_RELEASE=4.2.1 | |
103 | MILESTONE=5.0 |
|
103 | MILESTONE=5.0 | |
104 | VERSION=5.0.0 |
|
104 | VERSION=5.0.0 | |
105 | BRANCH=master |
|
105 | BRANCH=master | |
106 |
|
106 | |||
107 |
|
107 | |||
108 | 2. Create GitHub stats and finish release note |
|
108 | 2. Create GitHub stats and finish release note | |
109 | ---------------------------------------------- |
|
109 | ---------------------------------------------- | |
110 |
|
110 | |||
111 | .. note:: |
|
111 | .. note:: | |
112 |
|
112 | |||
113 | This step is optional if making a Beta or RC release. |
|
113 | This step is optional if making a Beta or RC release. | |
114 |
|
114 | |||
115 | .. note:: |
|
115 | .. note:: | |
116 |
|
116 | |||
117 | Before generating the GitHub stats, verify that all closed issues and pull |
|
117 | Before generating the GitHub stats, verify that all closed issues and pull | |
118 | requests have `appropriate milestones |
|
118 | requests have `appropriate milestones | |
119 | <https://github.com/ipython/ipython/wiki/Dev:-GitHub-workflow#milestones>`_. |
|
119 | <https://github.com/ipython/ipython/wiki/Dev:-GitHub-workflow#milestones>`_. | |
120 | `This search |
|
120 | `This search | |
121 | <https://github.com/ipython/ipython/issues?q=is%3Aclosed+no%3Amilestone+is%3Aissue>`_ |
|
121 | <https://github.com/ipython/ipython/issues?q=is%3Aclosed+no%3Amilestone+is%3Aissue>`_ | |
122 | should return no results before creating the GitHub stats. |
|
122 | should return no results before creating the GitHub stats. | |
123 |
|
123 | |||
124 | If a major release: |
|
124 | If a major release: | |
125 |
|
125 | |||
126 | - merge any pull request notes into what's new:: |
|
126 | - merge any pull request notes into what's new:: | |
127 |
|
127 | |||
128 | python tools/update_whatsnew.py |
|
128 | python tools/update_whatsnew.py | |
129 |
|
129 | |||
130 | - update ``docs/source/whatsnew/development.rst``, to ensure it covers |
|
130 | - update ``docs/source/whatsnew/development.rst``, to ensure it covers | |
131 | the major release features |
|
131 | the major release features | |
132 |
|
132 | |||
133 | - move the contents of ``development.rst`` to ``versionX.rst`` where ``X`` is |
|
133 | - move the contents of ``development.rst`` to ``versionX.rst`` where ``X`` is | |
134 | the numerical release version |
|
134 | the numerical release version | |
135 |
|
135 | |||
136 | - generate summary of GitHub contributions, which can be done with:: |
|
136 | - generate summary of GitHub contributions, which can be done with:: | |
137 |
|
137 | |||
138 | python tools/github_stats.py --milestone $MILESTONE > stats.rst |
|
138 | python tools/github_stats.py --milestone $MILESTONE > stats.rst | |
139 |
|
139 | |||
140 | which may need some manual cleanup of ``stats.rst``. Add the cleaned |
|
140 | which may need some manual cleanup of ``stats.rst``. Add the cleaned | |
141 | ``stats.rst`` results to ``docs/source/whatsnew/github-stats-X.rst`` |
|
141 | ``stats.rst`` results to ``docs/source/whatsnew/github-stats-X.rst`` | |
142 | where ``X`` is the numerical release version (don't forget to add it to |
|
142 | where ``X`` is the numerical release version (don't forget to add it to | |
143 | the git repository as well). If creating a major release, make a new |
|
143 | the git repository as well). If creating a major release, make a new | |
144 | ``github-stats-X.rst`` file; if creating a minor release, the content |
|
144 | ``github-stats-X.rst`` file; if creating a minor release, the content | |
145 | from ``stats.rst`` may simply be added to the top of an existing |
|
145 | from ``stats.rst`` may simply be added to the top of an existing | |
146 | ``github-stats-X.rst`` file. |
|
146 | ``github-stats-X.rst`` file. | |
147 |
|
147 | |||
148 | - Edit ``docs/source/whatsnew/index.rst`` to list the new ``github-stats-X`` |
|
148 | - Edit ``docs/source/whatsnew/index.rst`` to list the new ``github-stats-X`` | |
149 | file you just created. |
|
149 | file you just created. | |
150 |
|
150 | |||
151 | - You do not need to temporarily remove the first entry called |
|
151 | - You do not need to temporarily remove the first entry called | |
152 | ``development``, nor re-add it after the release, it will automatically be |
|
152 | ``development``, nor re-add it after the release, it will automatically be | |
153 | hidden when releasing a stable version of IPython (if ``_version_extra`` |
|
153 | hidden when releasing a stable version of IPython (if ``_version_extra`` | |
154 | in ``release.py`` is an empty string. |
|
154 | in ``release.py`` is an empty string. | |
155 |
|
155 | |||
156 | Make sure that the stats file has a header or it won't be rendered in |
|
156 | Make sure that the stats file has a header or it won't be rendered in | |
157 | the final documentation. |
|
157 | the final documentation. | |
158 |
|
158 | |||
159 | To find duplicates and update `.mailmap`, use:: |
|
159 | To find duplicates and update `.mailmap`, use:: | |
160 |
|
160 | |||
161 | git log --format="%aN <%aE>" $PREV_RELEASE... | sort -u -f |
|
161 | git log --format="%aN <%aE>" $PREV_RELEASE... | sort -u -f | |
162 |
|
162 | |||
163 | If a minor release you might need to do some of the above points manually, and |
|
163 | If a minor release you might need to do some of the above points manually, and | |
164 | forward port the changes. |
|
164 | forward port the changes. | |
165 |
|
165 | |||
166 | 3. Make sure the repository is clean |
|
166 | 3. Make sure the repository is clean | |
167 | ------------------------------------ |
|
167 | ------------------------------------ | |
168 |
|
168 | |||
169 | of any file that could be problematic. |
|
169 | of any file that could be problematic. | |
170 | Remove all non-tracked files with: |
|
170 | Remove all non-tracked files with: | |
171 |
|
171 | |||
172 | .. code:: |
|
172 | .. code:: | |
173 |
|
173 | |||
174 | git clean -xfdi |
|
174 | git clean -xfdi | |
175 |
|
175 | |||
176 | This will ask for confirmation before removing all untracked files. Make |
|
176 | This will ask for confirmation before removing all untracked files. Make | |
177 | sure the ``dist/`` folder is clean to avoid any stale builds from |
|
177 | sure the ``dist/`` folder is clean to avoid any stale builds from | |
178 | previous build attempts. |
|
178 | previous build attempts. | |
179 |
|
179 | |||
180 |
|
180 | |||
181 | 4. Update the release version number |
|
181 | 4. Update the release version number | |
182 | ------------------------------------ |
|
182 | ------------------------------------ | |
183 |
|
183 | |||
184 | Edit ``IPython/core/release.py`` to have the current version. |
|
184 | Edit ``IPython/core/release.py`` to have the current version. | |
185 |
|
185 | |||
186 | in particular, update version number and ``_version_extra`` content in |
|
186 | in particular, update version number and ``_version_extra`` content in | |
187 | ``IPython/core/release.py``. |
|
187 | ``IPython/core/release.py``. | |
188 |
|
188 | |||
189 | Step 5 will validate your changes automatically, but you might still want to |
|
189 | Step 5 will validate your changes automatically, but you might still want to | |
190 | make sure the version number matches pep440. |
|
190 | make sure the version number matches pep440. | |
191 |
|
191 | |||
192 | In particular, ``rc`` and ``beta`` are not separated by ``.`` or the ``sdist`` |
|
192 | In particular, ``rc`` and ``beta`` are not separated by ``.`` or the ``sdist`` | |
193 | and ``bdist`` will appear as different releases. For example, a valid version |
|
193 | and ``bdist`` will appear as different releases. For example, a valid version | |
194 | number for a release candidate (rc) release is: ``1.3rc1``. Notice that there |
|
194 | number for a release candidate (rc) release is: ``1.3rc1``. Notice that there | |
195 | is no separator between the '3' and the 'r'. Check the environment variable |
|
195 | is no separator between the '3' and the 'r'. Check the environment variable | |
196 | ``$VERSION`` as well. |
|
196 | ``$VERSION`` as well. | |
197 |
|
197 | |||
198 | You will likely just have to modify/comment/uncomment one of the lines setting |
|
198 | You will likely just have to modify/comment/uncomment one of the lines setting | |
199 | ``_version_extra`` |
|
199 | ``_version_extra`` | |
200 |
|
200 | |||
201 |
|
201 | |||
202 | 5. Run the `tools/build_release` script |
|
202 | 5. Run the `tools/build_release` script | |
203 | --------------------------------------- |
|
203 | --------------------------------------- | |
204 |
|
204 | |||
205 | Running ``tools/build_release`` does all the file checking and building that |
|
205 | Running ``tools/build_release`` does all the file checking and building that | |
206 | the real release script will do. This makes test installations, checks that |
|
206 | the real release script will do. This makes test installations, checks that | |
207 | the build procedure runs OK, and tests other steps in the release process. |
|
207 | the build procedure runs OK, and tests other steps in the release process. | |
208 |
|
208 | |||
209 | The ``build_release`` script will in particular verify that the version number |
|
209 | The ``build_release`` script will in particular verify that the version number | |
210 | match PEP 440, in order to avoid surprise at the time of build upload. |
|
210 | match PEP 440, in order to avoid surprise at the time of build upload. | |
211 |
|
211 | |||
212 | We encourage creating a test build of the docs as well. |
|
212 | We encourage creating a test build of the docs as well. | |
213 |
|
213 | |||
214 | 6. Create and push the new tag |
|
214 | 6. Create and push the new tag | |
215 | ------------------------------ |
|
215 | ------------------------------ | |
216 |
|
216 | |||
217 | Commit the changes to release.py:: |
|
217 | Commit the changes to release.py:: | |
218 |
|
218 | |||
219 | git commit -am "release $VERSION" |
|
219 | git commit -am "release $VERSION" | |
220 | git push origin $BRANCH |
|
220 | git push origin $BRANCH | |
221 |
|
221 | |||
222 | Create and push the tag:: |
|
222 | Create and push the tag:: | |
223 |
|
223 | |||
224 | git tag -am "release $VERSION" "$VERSION" |
|
224 | git tag -am "release $VERSION" "$VERSION" | |
225 | git push origin --tags |
|
225 | git push origin --tags | |
226 |
|
226 | |||
227 | Update release.py back to ``x.y-dev`` or ``x.y-maint``, and re-add the |
|
227 | Update release.py back to ``x.y-dev`` or ``x.y-maint``, and re-add the | |
228 | ``development`` entry in ``docs/source/whatsnew/index.rst`` and push:: |
|
228 | ``development`` entry in ``docs/source/whatsnew/index.rst`` and push:: | |
229 |
|
229 | |||
230 | git commit -am "back to development" |
|
230 | git commit -am "back to development" | |
231 | git push origin $BRANCH |
|
231 | git push origin $BRANCH | |
232 |
|
232 | |||
233 | Now checkout the tag we just made:: |
|
233 | Now checkout the tag we just made:: | |
234 |
|
234 | |||
235 | git checkout $VERSION |
|
235 | git checkout $VERSION | |
236 |
|
236 | |||
237 | 7. Run the release script |
|
237 | 7. Run the release script | |
238 | ------------------------- |
|
238 | ------------------------- | |
239 |
|
239 | |||
240 | Run the ``release`` script, this step requires having a current wheel, Python |
|
240 | Run the ``release`` script, this step requires having a current wheel, Python | |
241 | >=3.4 and Python 2.7.:: |
|
241 | >=3.4 and Python 2.7.:: | |
242 |
|
242 | |||
243 | ./tools/release |
|
243 | ./tools/release | |
244 |
|
244 | |||
245 | This makes the tarballs and wheels, and puts them under the ``dist/`` |
|
245 | This makes the tarballs and wheels, and puts them under the ``dist/`` | |
246 | folder. Be sure to test the ``wheels`` and the ``sdist`` locally before |
|
246 | folder. Be sure to test the ``wheels`` and the ``sdist`` locally before | |
247 | uploading them to PyPI. We do not use an universal wheel as each wheel |
|
247 | uploading them to PyPI. We do not use an universal wheel as each wheel | |
248 | installs an ``ipython2`` or ``ipython3`` script, depending on the version of |
|
248 | installs an ``ipython2`` or ``ipython3`` script, depending on the version of | |
249 | Python it is built for. Using an universal wheel would prevent this. |
|
249 | Python it is built for. Using an universal wheel would prevent this. | |
250 |
|
250 | |||
251 | Use the following to actually upload the result of the build:: |
|
251 | Use the following to actually upload the result of the build:: | |
252 |
|
252 | |||
253 | ./tools/release upload |
|
253 | ./tools/release upload | |
254 |
|
254 | |||
255 | It should posts them to ``archive.ipython.org`` and to PyPI. |
|
255 | It should posts them to ``archive.ipython.org`` and to PyPI. | |
256 |
|
256 | |||
257 | PyPI/Warehouse will automatically hide previous releases. If you are uploading |
|
257 | PyPI/Warehouse will automatically hide previous releases. If you are uploading | |
258 | a non-stable version, make sure to log-in to PyPI and un-hide previous version. |
|
258 | a non-stable version, make sure to log-in to PyPI and un-hide previous version. | |
259 |
|
259 | |||
260 |
|
260 | |||
261 | 8. Draft a short release announcement |
|
261 | 8. Draft a short release announcement | |
262 | ------------------------------------- |
|
262 | ------------------------------------- | |
263 |
|
263 | |||
264 | The announcement should include: |
|
264 | The announcement should include: | |
265 |
|
265 | |||
266 | - release highlights |
|
266 | - release highlights | |
267 | - a link to the html version of the *What's new* section of the documentation |
|
267 | - a link to the html version of the *What's new* section of the documentation | |
268 | - a link to upgrade or installation tips (if necessary) |
|
268 | - a link to upgrade or installation tips (if necessary) | |
269 |
|
269 | |||
270 | Post the announcement to the mailing list and or blog, and link from Twitter. |
|
270 | Post the announcement to the mailing list and or blog, and link from Twitter. | |
271 |
|
271 | |||
272 | .. note:: |
|
272 | .. note:: | |
273 |
|
273 | |||
274 | If you are doing a RC or Beta, you can likely skip the next steps. |
|
274 | If you are doing a RC or Beta, you can likely skip the next steps. | |
275 |
|
275 | |||
276 | 9. Update milestones on GitHub |
|
276 | 9. Update milestones on GitHub | |
277 | ------------------------------- |
|
277 | ------------------------------- | |
278 |
|
278 | |||
279 | These steps will bring milestones up to date: |
|
279 | These steps will bring milestones up to date: | |
280 |
|
280 | |||
281 | - close the just released milestone |
|
281 | - close the just released milestone | |
282 | - open a new milestone for the next release (x, y+1), if the milestone doesn't |
|
282 | - open a new milestone for the next release (x, y+1), if the milestone doesn't | |
283 | exist already |
|
283 | exist already | |
284 |
|
284 | |||
285 | 10. Update the IPython website |
|
285 | 10. Update the IPython website | |
286 | ------------------------------ |
|
286 | ------------------------------ | |
287 |
|
287 | |||
288 | The IPython website should document the new release: |
|
288 | The IPython website should document the new release: | |
289 |
|
289 | |||
290 | - add release announcement (news, announcements) |
|
290 | - add release announcement (news, announcements) | |
291 | - update current version and download links |
|
291 | - update current version and download links | |
292 | - update links on the documentation page (especially if a major release) |
|
292 | - update links on the documentation page (especially if a major release) | |
293 |
|
293 | |||
294 | 11. Update readthedocs |
|
294 | 11. Update readthedocs | |
295 | ---------------------- |
|
295 | ---------------------- | |
296 |
|
296 | |||
297 | Make sure to update readthedocs and set the latest tag as stable, as well as |
|
297 | Make sure to update readthedocs and set the latest tag as stable, as well as | |
298 | checking that previous release is still building under its own tag. |
|
298 | checking that previous release is still building under its own tag. | |
299 |
|
299 | |||
300 | 12. Update the Conda-Forge feedstock |
|
300 | 12. Update the Conda-Forge feedstock | |
301 | ------------------------------------ |
|
301 | ------------------------------------ | |
302 |
|
302 | |||
303 | Follow the instructions on `the repository <https://github.com/conda-forge/ipython-feedstock>`_ |
|
303 | Follow the instructions on `the repository <https://github.com/conda-forge/ipython-feedstock>`_ | |
304 |
|
304 | |||
305 | 13. Celebrate! |
|
305 | 13. Celebrate! | |
306 | -------------- |
|
306 | -------------- | |
307 |
|
307 | |||
308 | Celebrate the release and please thank the contributors for their work. Great |
|
308 | Celebrate the release and please thank the contributors for their work. Great | |
309 | job! |
|
309 | job! | |
310 |
|
310 | |||
311 |
|
311 | |||
312 |
|
312 | |||
313 | Old Documentation |
|
313 | Old Documentation | |
314 | ================= |
|
314 | ================= | |
315 |
|
315 | |||
316 | Out of date documentation is still available and have been kept for archival purposes. |
|
316 | Out of date documentation is still available and have been kept for archival purposes. | |
317 |
|
317 | |||
318 | .. note:: |
|
318 | .. note:: | |
319 |
|
319 | |||
320 | Developers documentation used to be on the IPython wiki, but are now out of |
|
320 | Developers documentation used to be on the IPython wiki, but are now out of | |
321 | date. The wiki is though still available for historical reasons: `Old IPython |
|
321 | date. The wiki is though still available for historical reasons: `Old IPython | |
322 | GitHub Wiki. <https://github.com/ipython/ipython/wiki/Dev:-Index>`_ |
|
322 | GitHub Wiki. <https://github.com/ipython/ipython/wiki/Dev:-Index>`_ |
@@ -1,69 +1,69 b'' | |||||
1 | .. Developers should add in this file, during each release cycle, information |
|
1 | .. Developers should add in this file, during each release cycle, information | |
2 | .. about important changes they've made, in a summary format that's meant for |
|
2 | .. about important changes they've made, in a summary format that's meant for | |
3 | .. end users. For each release we normally have three sections: features, bug |
|
3 | .. end users. For each release we normally have three sections: features, bug | |
4 | .. fixes and api breakage. |
|
4 | .. fixes and api breakage. | |
5 | .. Please remember to credit the authors of the contributions by name, |
|
5 | .. Please remember to credit the authors of the contributions by name, | |
6 | .. especially when they are new users or developers who do not regularly |
|
6 | .. especially when they are new users or developers who do not regularly | |
7 | .. participate in IPython's development. |
|
7 | .. participate in IPython's development. | |
8 |
|
8 | |||
9 | .. _whatsnew_index: |
|
9 | .. _whatsnew_index: | |
10 |
|
10 | |||
11 | ===================== |
|
11 | ===================== | |
12 | What's new in IPython |
|
12 | What's new in IPython | |
13 | ===================== |
|
13 | ===================== | |
14 |
|
14 | |||
15 | .. |
|
15 | .. | |
16 |
this will appear in the docs if we are not releasing a versin (ie i |
|
16 | this will appear in the docs if we are not releasing a version (ie if | |
17 | `_version_extra` in release.py is empty string |
|
17 | `_version_extra` in release.py is an empty string) | |
18 |
|
18 | |||
19 | .. only:: ipydev |
|
19 | .. only:: ipydev | |
20 |
|
20 | |||
21 | Development version in-progress features: |
|
21 | Development version in-progress features: | |
22 |
|
22 | |||
23 | .. toctree:: |
|
23 | .. toctree:: | |
24 |
|
24 | |||
25 | development |
|
25 | development | |
26 |
|
26 | |||
27 | .. |
|
27 | .. | |
28 |
this make a hidden toctree that |
|
28 | this makes a hidden toctree that keeps sphinx from complaining about | |
29 | included nowhere when building docs for stable |
|
29 | documents included nowhere when building docs for stable | |
30 |
|
30 | |||
31 | .. only:: ipystable |
|
31 | .. only:: ipystable | |
32 |
|
32 | |||
33 | .. toctree:: |
|
33 | .. toctree:: | |
34 | :hidden: |
|
34 | :hidden: | |
35 |
|
35 | |||
36 | development |
|
36 | development | |
37 |
|
37 | |||
38 | This section documents the changes that have been made in various versions of |
|
38 | This section documents the changes that have been made in various versions of | |
39 | IPython. Users should consult these pages to learn about new features, bug |
|
39 | IPython. Users should consult these pages to learn about new features, bug | |
40 | fixes and backwards incompatibilities. Developers should summarize the |
|
40 | fixes and backwards incompatibilities. Developers should summarize the | |
41 | development work they do here in a user friendly format. |
|
41 | development work they do here in a user friendly format. | |
42 |
|
42 | |||
43 | .. toctree:: |
|
43 | .. toctree:: | |
44 | :maxdepth: 1 |
|
44 | :maxdepth: 1 | |
45 |
|
45 | |||
46 | version7 |
|
46 | version7 | |
47 | github-stats-7 |
|
47 | github-stats-7 | |
48 | version6 |
|
48 | version6 | |
49 | github-stats-6 |
|
49 | github-stats-6 | |
50 | version5 |
|
50 | version5 | |
51 | github-stats-5 |
|
51 | github-stats-5 | |
52 | version4 |
|
52 | version4 | |
53 | github-stats-4 |
|
53 | github-stats-4 | |
54 | version3 |
|
54 | version3 | |
55 | github-stats-3 |
|
55 | github-stats-3 | |
56 | version3_widget_migration |
|
56 | version3_widget_migration | |
57 | version2.0 |
|
57 | version2.0 | |
58 | github-stats-2.0 |
|
58 | github-stats-2.0 | |
59 | version1.0 |
|
59 | version1.0 | |
60 | github-stats-1.0 |
|
60 | github-stats-1.0 | |
61 | version0.13 |
|
61 | version0.13 | |
62 | github-stats-0.13 |
|
62 | github-stats-0.13 | |
63 | version0.12 |
|
63 | version0.12 | |
64 | github-stats-0.12 |
|
64 | github-stats-0.12 | |
65 | version0.11 |
|
65 | version0.11 | |
66 | github-stats-0.11 |
|
66 | github-stats-0.11 | |
67 | version0.10 |
|
67 | version0.10 | |
68 | version0.9 |
|
68 | version0.9 | |
69 | version0.8 |
|
69 | version0.8 |
@@ -1,33 +1,35 b'' | |||||
1 | #!/usr/bin/env python3 |
|
1 | #!/usr/bin/env python3 | |
2 | """IPython release build script. |
|
2 | """IPython release build script. | |
3 | """ |
|
3 | """ | |
4 | import os |
|
4 | import os | |
5 | from shutil import rmtree |
|
5 | from shutil import rmtree | |
6 |
|
6 | |||
7 | from toollib import sh, pjoin, get_ipdir, cd, execfile, sdists, buildwheels |
|
7 | from toollib import sh, pjoin, get_ipdir, cd, execfile, sdists, buildwheels | |
8 |
|
8 | |||
9 | def build_release(): |
|
9 | def build_release(): | |
10 |
|
10 | |||
11 | # Get main ipython dir, this will raise if it doesn't pass some checks |
|
11 | # Get main ipython dir, this will raise if it doesn't pass some checks | |
12 | ipdir = get_ipdir() |
|
12 | ipdir = get_ipdir() | |
13 | cd(ipdir) |
|
13 | cd(ipdir) | |
14 |
|
14 | |||
15 | # Load release info |
|
15 | # Load release info | |
16 | execfile(pjoin('IPython', 'core', 'release.py'), globals()) |
|
16 | execfile(pjoin('IPython', 'core', 'release.py'), globals()) | |
17 |
|
17 | |||
18 | with open('docs/source/whatsnew/index.rst') as f: |
|
18 | with open('docs/source/whatsnew/index.rst') as f: | |
19 | if ' development' in f.read(): |
|
19 | if ' development' in f.read(): | |
20 | raise ValueError("Please remove `development` from what's new toctree for release") |
|
20 | pass | |
|
21 | # raise ValueError("Please remove `development` from what's new toctree for release") | |||
|
22 | ||||
21 |
|
23 | |||
22 | # Cleanup |
|
24 | # Cleanup | |
23 | for d in ['build', 'dist', pjoin('docs', 'build'), pjoin('docs', 'dist'), |
|
25 | for d in ['build', 'dist', pjoin('docs', 'build'), pjoin('docs', 'dist'), | |
24 | pjoin('docs', 'source', 'api', 'generated')]: |
|
26 | pjoin('docs', 'source', 'api', 'generated')]: | |
25 | if os.path.isdir(d): |
|
27 | if os.path.isdir(d): | |
26 | rmtree(d) |
|
28 | rmtree(d) | |
27 |
|
29 | |||
28 | # Build source and binary distros |
|
30 | # Build source and binary distros | |
29 | sh(sdists) |
|
31 | sh(sdists) | |
30 | buildwheels() |
|
32 | buildwheels() | |
31 |
|
33 | |||
32 | if __name__ == '__main__': |
|
34 | if __name__ == '__main__': | |
33 | build_release() |
|
35 | build_release() |
General Comments 0
You need to be logged in to leave comments.
Login now