Show More
@@ -12,44 +12,6 b'' | |||||
12 | What's new |
|
12 | What's new | |
13 | ========== |
|
13 | ========== | |
14 |
|
14 | |||
15 | .. contents:: |
|
|||
16 | .. |
|
|||
17 | 1 Release dev |
|
|||
18 | 1.1 New features |
|
|||
19 | 1.2 Bug fixes |
|
|||
20 | 1.3 Backwards incompatible changes |
|
|||
21 | 2 Release 0.10 |
|
|||
22 | 2.1 New features |
|
|||
23 | 2.2 Bug fixes |
|
|||
24 | 2.3 Backwards incompatible changes |
|
|||
25 | 3 Release 0.9.1 |
|
|||
26 | 4 Release 0.9 |
|
|||
27 | 4.1 New features |
|
|||
28 | 4.2 Bug fixes |
|
|||
29 | 4.3 Backwards incompatible changes |
|
|||
30 | 4.4 Changes merged in from IPython1 |
|
|||
31 | 4.4.1 New features |
|
|||
32 | 4.4.2 Bug fixes |
|
|||
33 | 4.4.3 Backwards incompatible changes |
|
|||
34 | 5 Release 0.8.4 |
|
|||
35 | 6 Release 0.8.3 |
|
|||
36 | 7 Release 0.8.2 |
|
|||
37 | 8 Older releases |
|
|||
38 | .. |
|
|||
39 |
|
||||
40 | Release dev |
|
|||
41 | =========== |
|
|||
42 |
|
||||
43 | New features |
|
|||
44 | ------------ |
|
|||
45 |
|
||||
46 | Bug fixes |
|
|||
47 | --------- |
|
|||
48 |
|
||||
49 | Backwards incompatible changes |
|
|||
50 | ------------------------------ |
|
|||
51 |
|
||||
52 |
|
||||
53 | Release 0.10 |
|
15 | Release 0.10 | |
54 | ============ |
|
16 | ============ | |
55 |
|
17 | |||
@@ -90,6 +52,7 b' alphabetical order by first name):' | |||||
90 | * Robert Kern: several extensions. |
|
52 | * Robert Kern: several extensions. | |
91 | * Sameer D'Costa: help on critical bug #269966. |
|
53 | * Sameer D'Costa: help on critical bug #269966. | |
92 | * Stephan Peijnik: feedback on Debian compliance and many man pages. |
|
54 | * Stephan Peijnik: feedback on Debian compliance and many man pages. | |
|
55 | * Steven Bethard: we are now shipping his :mod:`argparse` module. | |||
93 | * Tom Fetherston: many improvements to :mod:`IPython.demo` module. |
|
56 | * Tom Fetherston: many improvements to :mod:`IPython.demo` module. | |
94 | * Ville Vainio: lots of work everywhere (features, bug fixes, etc). |
|
57 | * Ville Vainio: lots of work everywhere (features, bug fixes, etc). | |
95 | * Vishal Vasta: ssh support in ipcluster. |
|
58 | * Vishal Vasta: ssh support in ipcluster. | |
@@ -126,8 +89,6 b' New features' | |||||
126 | using the `Numpy Documentation Standard`_ for all docstrings, and we have |
|
89 | using the `Numpy Documentation Standard`_ for all docstrings, and we have | |
127 | tried to update as many existing ones as possible to this format. |
|
90 | tried to update as many existing ones as possible to this format. | |
128 |
|
91 | |||
129 | .. _Numpy Documentation Standard: http://projects.scipy.org/numpy/wiki/CodingStyleGuidelines#docstring-standard |
|
|||
130 |
|
||||
131 | * The new :mod:`IPython.Extensions.ipy_pretty` extension by Robert Kern |
|
92 | * The new :mod:`IPython.Extensions.ipy_pretty` extension by Robert Kern | |
132 | provides configurable pretty-printing. |
|
93 | provides configurable pretty-printing. | |
133 |
|
94 | |||
@@ -140,7 +101,8 b' New features' | |||||
140 | :mod:`IPython.external` package, so we can use it internally and it is also |
|
101 | :mod:`IPython.external` package, so we can use it internally and it is also | |
141 | available to any IPython user. By installing it in this manner, we ensure |
|
102 | available to any IPython user. By installing it in this manner, we ensure | |
142 | zero conflicts with any system-wide installation you may already have while |
|
103 | zero conflicts with any system-wide installation you may already have while | |
143 | minimizing external dependencies for new users. |
|
104 | minimizing external dependencies for new users. In IPython 0.10, We ship | |
|
105 | argparse version 1.0. | |||
144 |
|
106 | |||
145 | * An improved and much more robust test suite, that runs groups of tests in |
|
107 | * An improved and much more robust test suite, that runs groups of tests in | |
146 | separate subprocesses using either Nose or Twisted's :command:`trial` runner |
|
108 | separate subprocesses using either Nose or Twisted's :command:`trial` runner | |
@@ -173,8 +135,6 b' New features' | |||||
173 | should be considered a technology preview. We plan on changing the API in |
|
135 | should be considered a technology preview. We plan on changing the API in | |
174 | significant ways before it is final. |
|
136 | significant ways before it is final. | |
175 |
|
137 | |||
176 | * The :mod:`argparse` module has been added to :mod:`IPython.external`. |
|
|||
177 |
|
||||
178 | * Full description of the security model added to the docs. |
|
138 | * Full description of the security model added to the docs. | |
179 |
|
139 | |||
180 | * cd completer: show bookmarks if no other completions are available. |
|
140 | * cd completer: show bookmarks if no other completions are available. | |
@@ -188,6 +148,10 b' New features' | |||||
188 | * %edit: If you do '%edit pasted_block', pasted_block variable gets updated |
|
148 | * %edit: If you do '%edit pasted_block', pasted_block variable gets updated | |
189 | with new data (so repeated editing makes sense) |
|
149 | with new data (so repeated editing makes sense) | |
190 |
|
150 | |||
|
151 | .. _Numpy Documentation Standard: http://projects.scipy.org/numpy/wiki/CodingStyleGuidelines#docstring-standard | |||
|
152 | ||||
|
153 | .. _argparse: http://code.google.com/p/argparse/ | |||
|
154 | ||||
191 | Bug fixes |
|
155 | Bug fixes | |
192 | --------- |
|
156 | --------- | |
193 |
|
157 | |||
@@ -240,6 +204,9 b' Bug fixes' | |||||
240 | * Bug #274067 'The code in get_home_dir is broken for py2exe' was |
|
204 | * Bug #274067 'The code in get_home_dir is broken for py2exe' was | |
241 | fixed. |
|
205 | fixed. | |
242 |
|
206 | |||
|
207 | * Many other small bug fixes not listed here by number (see the bzr log for | |||
|
208 | more info). | |||
|
209 | ||||
243 | Backwards incompatible changes |
|
210 | Backwards incompatible changes | |
244 | ------------------------------ |
|
211 | ------------------------------ | |
245 |
|
212 |
@@ -164,6 +164,45 b' ready to be merged. What types of things will we be looking for:' | |||||
164 | Once your changes have been reviewed and approved, someone will merge them |
|
164 | Once your changes have been reviewed and approved, someone will merge them | |
165 | into the main development branch. |
|
165 | into the main development branch. | |
166 |
|
166 | |||
|
167 | ||||
|
168 | Some notes for core developers when merging third-party contributions | |||
|
169 | ===================================================================== | |||
|
170 | ||||
|
171 | Core developers, who ultimately merge any approved branch (from themselves, | |||
|
172 | another developer, or any third-party contribution) will typically use | |||
|
173 | :command:`bzr merge` to merge the branch into the trunk and push it to the main | |||
|
174 | Launcphad site. This is a short list of things to keep in mind when doing this | |||
|
175 | process, so that the project history is easy to understand in the long run, and | |||
|
176 | that generating release notes is as painless and accurate as possible. | |||
|
177 | ||||
|
178 | - When you merge any non-trivial functionality (from one small bug fix to a big | |||
|
179 | feature branch), please remember to always edit the changes_ file | |||
|
180 | accordingly. This file has one main section for each release, and if you | |||
|
181 | edit it as you go, noting what new features, bug fixes or API changes you | |||
|
182 | have made, the release notes will be almost finished when they are needed | |||
|
183 | later. This is much easier if done when you merge the work, rather than | |||
|
184 | weeks or months later by re-reading a massive Bazaar log. | |||
|
185 | ||||
|
186 | - When big merges are done, the practice of putting a summary commit message in | |||
|
187 | the merge is *extremely* useful. It makes this kind of job much nicer, | |||
|
188 | because that summary log message can be almost copy/pasted without changes, | |||
|
189 | if it was well written, rather than dissecting the next-level messages from | |||
|
190 | the individual commits. | |||
|
191 | ||||
|
192 | - It's important that we remember to always credit who gave us something if | |||
|
193 | it's not the committer. In general, we have been fairly good on this front, | |||
|
194 | this is just a reminder to keep things up. As a note, if you are ever | |||
|
195 | committing something that is completely (or almost so) a third-party | |||
|
196 | contribution, do the commit as:: | |||
|
197 | ||||
|
198 | $ bzr commit --author="Someone Else" | |||
|
199 | ||||
|
200 | This way it will show that name separately in the log, which makes it even | |||
|
201 | easier to spot. Obviously we often rework third party contributions | |||
|
202 | extensively, but this is still good to keep in mind for cases when we don't | |||
|
203 | touch the code too much. | |||
|
204 | ||||
|
205 | ||||
167 | Documentation |
|
206 | Documentation | |
168 | ============= |
|
207 | ============= | |
169 |
|
208 | |||
@@ -317,12 +356,18 b' it, you can find this script in the :file:`scripts` directory)::' | |||||
317 |
|
356 | |||
318 | $ iptest |
|
357 | $ iptest | |
319 |
|
358 | |||
320 | This command runs Nose with the proper options and extensions. By default, |
|
359 | This command colects all IPython tests into separate groups, and then calls | |
321 | :command:`iptest` runs the entire IPython test suite (skipping tests that may |
|
360 | either Nose with the proper options and extensions, or Twisted's | |
322 | be platform-specific or which depend on tools you may not have). But you can |
|
361 | :command:`trial`. This ensures that tests that need the Twisted reactor | |
323 | also use it to run only one specific test file, or a specific test function. |
|
362 | management facilities execute separate of Nose. If any individual test group | |
324 | For example, this will run only the :file:`test_magic` file from the test |
|
363 | fails, :command:`iptest` will print what you need to type so you can rerun that | |
325 | suite:: |
|
364 | particular test group alone for debugging. | |
|
365 | ||||
|
366 | By default, :command:`iptest` runs the entire IPython test | |||
|
367 | suite (skipping tests that may be platform-specific or which depend on tools | |||
|
368 | you may not have). But you can also use it to run only one specific test file, | |||
|
369 | or a specific test function. For example, this will run only the | |||
|
370 | :file:`test_magic` file from the test suite:: | |||
326 |
|
371 | |||
327 | $ iptest IPython.tests.test_magic |
|
372 | $ iptest IPython.tests.test_magic | |
328 | ---------------------------------------------------------------------- |
|
373 | ---------------------------------------------------------------------- | |
@@ -345,36 +390,6 b' nosetests option. For example, you can use ``--pdb`` or ``--pdb-failures`` to' | |||||
345 | automatically activate the interactive Pdb debugger on errors or failures. See |
|
390 | automatically activate the interactive Pdb debugger on errors or failures. See | |
346 | the nosetests documentation for further details. |
|
391 | the nosetests documentation for further details. | |
347 |
|
392 | |||
348 | .. warning:: |
|
|||
349 |
|
||||
350 | Note that right now we have a nasty interaction between ipdoctest and |
|
|||
351 | twisted. Until we figure this out, please use the following instructions to |
|
|||
352 | ensure that at least you run all the tests. |
|
|||
353 |
|
||||
354 | Right now, if you now run:: |
|
|||
355 |
|
||||
356 | $ iptest [any options] [any submodules] |
|
|||
357 |
|
||||
358 | it will NOT load ipdoctest but won't cause any Twisted problems. |
|
|||
359 |
|
||||
360 | Once you're happy that you didn't break Twisted, run:: |
|
|||
361 |
|
||||
362 | $ iptest --with-ipdoctest [any options] [any submodules] |
|
|||
363 |
|
||||
364 | This MAY give a Twisted AlreadyCalledError exception at the end, but it will |
|
|||
365 | also correctly load up all of the ipython-specific tests and doctests. |
|
|||
366 |
|
||||
367 | The above can be made easier with a trivial shell alias:: |
|
|||
368 |
|
||||
369 | $ alias iptest2='iptest --with-ipdoctest' |
|
|||
370 |
|
||||
371 | So that you can run:: |
|
|||
372 |
|
||||
373 | $ iptest ... |
|
|||
374 | # Twisted happy |
|
|||
375 | # iptest2 ... |
|
|||
376 | # ignore possible Twisted error, this checks all the rest. |
|
|||
377 |
|
||||
378 |
|
393 | |||
379 | A few tips for writing tests |
|
394 | A few tips for writing tests | |
380 | ---------------------------- |
|
395 | ---------------------------- | |
@@ -450,6 +465,12 b' Release checklist' | |||||
450 | Most of the release process is automated by the :file:`release` script in the |
|
465 | Most of the release process is automated by the :file:`release` script in the | |
451 | :file:`tools` directory. This is just a handy reminder for the release manager. |
|
466 | :file:`tools` directory. This is just a handy reminder for the release manager. | |
452 |
|
467 | |||
|
468 | #. First, run :file:`build_release`, which does all the file checking and | |||
|
469 | building that the real release script will do. This will let you do test | |||
|
470 | installations, check that the build procedure runs OK, etc. You may want to | |||
|
471 | disable a few things like multi-version RPM building while testing, because | |||
|
472 | otherwise the build takes really long. | |||
|
473 | ||||
453 | #. Run the release script, which makes the tar.gz, eggs and Win32 .exe |
|
474 | #. Run the release script, which makes the tar.gz, eggs and Win32 .exe | |
454 | installer. It posts them to the site and registers the release with PyPI. |
|
475 | installer. It posts them to the site and registers the release with PyPI. | |
455 |
|
476 |
General Comments 0
You need to be logged in to leave comments.
Login now