Update stats and docs for 6.0 release.

docs/source/whatsnew/github-stats-6.rst

@@ -0,0 +1,49 b''
+Issues closed in the 6.x development cycle
+==========================================
+
+Issues closed in 6.0
+--------------------
+
+GitHub stats for 2017/04/10 - 2017/04/19 (milestone: 6.0)
+
+These lists are automatically generated, and may be incomplete or contain duplicates.
+
+We closed 49 issues and merged 145 pull requests.
+The full list can be seen `on GitHub <https://github.com/ipython/ipython/issues?q=milestone%3A6.0+>`__
+
+The following 34 authors contributed 176 commits.
+
+* Adam Eury
+* anantkaushik89
+* Antonino Ingargiola
+* Benjamin Ragan-Kelley
+* Carol Willing
+* Chilaka Ramakrishna
+* chillaranand
+* Denis S. Tereshchenko
+* Diego Garcia
+* fatData
+* Fermi paradox
+* fuho
+* Grant Nestor
+* Ian Rose
+* Jeroen Demeyer
+* kaushikanant
+* Keshav Ramaswamy
+* Matteo
+* Matthias Bussonnier
+* mbyt
+* Michael Käufl
+* michaelpacer
+* Moez Bouhlel
+* Pablo Galindo
+* Paul Ivanov
+* Piotr Przetacznik
+* Rounak Banik
+* sachet-mittal
+* Srinivas Reddy Thatiparthy
+* Tamir Bahar
+* Thomas Hisch
+* Thomas Kluyver
+* Utkarsh Upadhyay
+* Yuri Numerov

docs/source/coredev/index.rst

@@ -1,309 +1,310 b''
 .. _core_developer_guide:
 
 =================================
 Guide for IPython core Developers
 =================================
 
 This guide documents the development of IPython itself.  Alternatively,
 developers of third party tools and libraries that use IPython should see the
 :doc:`../development/index`.
 
 
 For instructions on how to make a developer install see :ref:`devinstall`.
 
 Backporting Pull requests
 -------------------------
 
 All pull requests should usually be made against ``master``, if a Pull Request
 need to be backported to an earlier release; then it should be tagged with the
 correct ``milestone``.
 
 If you are an admin on the IPython repository just mention the **backport bot** to
 do the work for you. The bot is evolving so instructions may be different. At
 the time of this writing you can use::
 
     @meeseeksdev[bot] backport to <branchname>
 
 The bot will attempt to backport the current pull-request and issue a PR if
 possible.
 
 .. note::
 
     The ``@`` and ``[dev]`` when mentioning the bot should be optional and can
     be omitted.
 
 
 Backport with ghpro
 -------------------
 
 We can also use `ghpro <https://pypi.python.org/pypi/ghpro>`
 to automatically list and apply the PR on other branches. For example:
 
 .. code-block:: bash
     
     $ backport-pr todo --milestone 5.2
     [...snip..]
     The following PRs have been backported
     9848
     9851
     9953
     9955
     The following PRs should be backported:
     9417
     9863
     9925
     9947
 
     $ backport-pr apply 5.x 9947
     [...snip...]
 
 
 .. _release_process:
 
 =======================
 IPython release process
 =======================
 
 This document contains the process that is used to create an IPython release.
 
 Conveniently, the ``release`` script in the ``tools`` directory of the ``IPython``
 repository automates most of the release process. This document serves as a
 handy reminder and checklist for the release manager.
 
 During the release process, you might need the extra following dependencies:
 
  - ``keyring`` to access your GitHub authentication tokens
  - ``graphviz`` to generate some graphs in the documentation
+ - ``ghpro`` to generate the stats
 
 Make sure you have all the required dependencies to run the tests as well.
 
 
 1. Set Environment variables
 ----------------------------
 
 Set environment variables to document previous release tag, current
 release milestone, current release version, and git tag.
 
 These variables may be used later to copy/paste as answers to the script
 questions instead of typing the appropriate command when the time comes. These
 variables are not used by the scripts directly; therefore, there is no need to
 ``export`` them. The format for bash is as follows, but note that these values
 are just an example valid only for the 5.0 release; you'll need to update them
 for the release you are actually making::
 
     PREV_RELEASE=4.2.1
     MILESTONE=5.0
     VERSION=5.0.0
     BRANCH=master
 
 
 2. Create GitHub stats and finish release note
 ----------------------------------------------
 
 .. note::
 
     This step is optional if making a Beta or RC release.
 
 .. note::
 
     Before generating the GitHub stats, verify that all closed issues and pull
     requests have `appropriate milestones
     <https://github.com/ipython/ipython/wiki/Dev:-GitHub-workflow#milestones>`_.
     `This search
     <https://github.com/ipython/ipython/issues?q=is%3Aclosed+no%3Amilestone+is%3Aissue>`_
     should return no results before creating the GitHub stats.
 
 If a major release:
 
     - merge any pull request notes into what's new::
 
           python tools/update_whatsnew.py
 
     - update ``docs/source/whatsnew/development.rst``, to ensure it covers
       the major release features
 
     - move the contents of ``development.rst`` to ``versionX.rst`` where ``X`` is
       the numerical release version
 
     - generate summary of GitHub contributions, which can be done with::
 
           python tools/github_stats.py --milestone $MILESTONE > stats.rst
 
       which may need some manual cleanup of ``stats.rst``. Add the cleaned
       ``stats.rst`` results to ``docs/source/whatsnew/github-stats-X.rst``
       where ``X`` is the numerical release version (don't forget to add it to
       the git repo as well). If creating a major release, make a new
       ``github-stats-X.rst`` file; if creating a minor release, the content
       from ``stats.rst`` may simply be added to the top of an existing
       ``github-stats-X.rst`` file.  Finally, edit
       ``docs/source/whatsnew/index.rst`` to list the new ``github-stats-X``
       file you just created and remove temporarily the first entry called
       ``development`` (you'll need to add it back after release).
 
       Make sure that the stats file has a header or it won't be rendered in
       the final documentation.
 
 To find duplicates and update `.mailmap`, use::
 
     git log --format="%aN <%aE>" $PREV_RELEASE... | sort -u -f
 
 If a minor release you might need to do some of the above points manually, and
 forward port the changes.
 
 3. Make sure the repository is clean
 ------------------------------------
 
 of any file that could be problematic.
    Remove all non-tracked files with:
 
    .. code::
 
        git clean -xfdi
 
    This will ask for confirmation before removing all untracked files. Make
    sure the ``dist/`` folder is clean to avoid any stale builds from
    previous build attempts.
 
 
 4. Update the release version number
 ------------------------------------
 
 Edit ``IPython/core/release.py`` to have the current version.
 
 in particular, update version number and ``_version_extra`` content in
 ``IPython/core/release.py``.
 
 Step 5 will validate your changes automatically, but you might still want to
 make sure the version number matches pep440.
 
 In particular, ``rc`` and ``beta`` are not separated by ``.`` or the ``sdist``
 and ``bdist`` will appear as different releases. For example, a valid version
 number for a release candidate (rc) release is: ``1.3rc1``. Notice that there
 is no separator between the '3' and the 'r'. Check the environment variable
 ``$VERSION`` as well.
 
 You will likely just have to modify/comment/uncomment one of the lines setting
 ``_version_extra``
 
 
 5. Run the `tools/build_release` script
 ---------------------------------------
 
 Running ``tools/build_release`` does all the file checking and building that
 the real release script will do. This makes test installations, checks that
 the build procedure runs OK, and tests other steps in the release process.
 
 The ``build_release`` script will in particular verify that the version number
 match PEP 440, in order to avoid surprise at the time of build upload.
 
 We encourage creating a test build of the docs as well.
 
 6. Create and push the new tag
 ------------------------------
 
 Commit the changes to release.py::
 
     git commit -am "release $VERSION"
     git push origin $BRANCH
 
 Create and push the tag::
 
     git tag -am "release $VERSION" "$VERSION"
     git push origin --tags
 
 Update release.py back to ``x.y-dev`` or ``x.y-maint``, and re-add the
 ``development`` entry in ``docs/source/whatsnew/index.rst`` and push::
 
     git commit -am "back to development"
     git push origin $BRANCH
 
 Now checkout the tag we just made::
 
     git checkout $VERSION
 
 7. Run the release script
 -------------------------
 
 Run the ``release`` script, this step requires having a current wheel, Python
 >=3.4 and Python 2.7.::
 
     ./tools/release
 
 This makes the tarballs and wheels, and puts them under the ``dist/``
 folder. Be sure to test the ``wheels``  and the ``sdist`` locally before
 uploading them to PyPI. We do not use an universal wheel as each wheel
 installs an ``ipython2`` or ``ipython3`` script, depending on the version of
 Python it is built for. Using an universal wheel would prevent this.
 
 Use the following to actually upload the result of the build::
 
     ./tools/release upload
 
 It should posts them to ``archive.ipython.org`` and to PyPI.
 
 PyPI/Warehouse will automatically hide previous releases. If you are uploading
 a non-stable version, make sure to log-in to PyPI and un-hide previous version.
 
 
 8. Draft a short release announcement
 -------------------------------------
 
 The announcement should include:
 
 - release highlights
 - a link to the html version of the *What's new* section of the documentation
 - a link to upgrade or installation tips (if necessary)
 
 Post the announcement to the mailing list and or blog, and link from Twitter.
 
 .. note::
 
     If you are doing a RC or Beta, you can likely skip the next steps.
 
 9. Update milestones on GitHub
 -------------------------------
 
 These steps will bring milestones up to date:
 
 - close the just released milestone
 - open a new milestone for the next release (x, y+1), if the milestone doesn't
   exist already
 
 10. Update the IPython website
 ------------------------------
 
 The IPython website should document the new release:
 
 - add release announcement (news, announcements)
 - update current version and download links
 - update links on the documentation page (especially if a major release)
 
 11. Update readthedocs
 ----------------------
 
 Make sure to update readthedocs and set the latest tag as stable, as well as
 checking that previous release is still building under its own tag.
 
 12. Update the Conda-Forge feedstock
 ------------------------------------
 
 Follow the instructions on `the repository <https://github.com/conda-forge/ipython-feedstock>`_
 
 13. Celebrate!
 --------------
 
 Celebrate the release and please thank the contributors for their work. Great
 job!
 
 
 
 Old Documentation
 =================
 
 Out of date documentation is still available and have been kept for archival purposes.
 
 .. note::
 
   Developers documentation used to be on the IPython wiki, but are now out of
   date. The wiki is though still available for historical reasons: `Old IPython
   GitHub Wiki.  <https://github.com/ipython/ipython/wiki/Dev:-Index>`_

docs/source/whatsnew/index.rst

@@ -1,45 +1,46 b''
 .. Developers should add in this file, during each release cycle, information
 .. about important changes they've made, in a summary format that's meant for
 .. end users.  For each release we normally have three sections: features,  bug
 .. fixes and api breakage.
 .. Please remember to credit the authors of the contributions by name,
 .. especially when they are new users or developers who do not regularly
 .. participate  in IPython's development.
 
 .. _whatsnew_index:
 
 =====================
 What's new in IPython
 =====================
 
 This section documents the changes that have been made in various versions of
 IPython. Users should consult these pages to learn about new features, bug
 fixes and backwards incompatibilities. Developers should summarize the
 development work they do here in a user friendly format.
 
 .. toctree::
    :maxdepth: 1
 
    version6
+   github-stats-6
    version5
    github-stats-5
    version4
    github-stats-4
    version3
    github-stats-3
    version3_widget_migration
    version2.0
    github-stats-2.0
    version1.0
    github-stats-1.0
    version0.13
    github-stats-0.13
    version0.12
    github-stats-0.12
    version0.11
    github-stats-0.11
    version0.10
    version0.9
    version0.8
 
 

docs/source/whatsnew/version6.rst

@@ -1,188 +1,188 b''
 ============
  6.x Series
 ============
 
 IPython 6.0
 ===========
 
-Released .... ...., 2017
+Released April 19th, 2017
 
 IPython 6 feature a major improvement in the completion machinery which is now
 capable of completing non-executed code. It is also the first version of IPython
 to stop compatibility with Python 2, which is still supported on the bugfix only
 5.x branch. Read below to have a non-exhaustive list of new features.
 
 Make sure you have pip > 9.0 before upgrading.
 You should be able to update by using:
 
 .. code::
 
     pip install ipython --upgrade
 
 
 .. note::
 
     If your pip version is greater of equal to pip 9.0.1 you will automatically get
     the most recent version of IPython compatible with your system: on Python 2 you 
     will get the latest IPython 5.x bugfix, while in Python 3
     you will get the latest 6.x stable version.
 
 New completion API and Interface
 --------------------------------
 
 The completer Completion API has seen an overhaul, and the new completer have
 plenty of improvement both from the end users of terminal IPython or for
 consumers of the API.
 
 This new API is capable of pulling completions from :any:`jedi`, thus allowing
 type inference on non-executed code. If :any:`jedi` is installed completion like
 the following are now becoming possible without code evaluation:
 
     >>> data = ['Number of users', 123_456]
     ... data[0].<tab>
 
 That is to say, IPython is now capable of inferring that `data[0]` is a string,
 and will suggest completions like `.capitalize`. The completion power of IPython
 will increase with new Jedi releases, and a number of bugs and more completions
 are already available on the development version of :any:`jedi` if you are curious.
 
 With the help of prompt toolkit, types of completions can be shown in the
 completer interface:
 
 .. image:: ../_images/jedi_type_inference_60.png
     :alt: Jedi showing ability to do type inference
     :align: center
     :width: 400px
     :target: ../_images/jedi_type_inference_60.png
 
 The appearance of the completer is controlled by the
 ``c.TerminalInteractiveShell.display_completions`` option that will show the
 type differently depending on the value among ``'column'``, ``'multicolumn'``
 and ``'readlinelike'``
 
 The use of Jedi also fulfills a number of requests and fix a number of bugs
 like case-insensitive completion, completion after division operator: See
 :ghpull:`10182`.
 
 Extra patches and updates will be needed to the :mod:`ipykernel` package for
 this feature to be available to other clients like Jupyter Notebook, Lab,
 Nteract, Hydrogen...
 
 The use of Jedi is should be barely noticeable on recent enough machines, but 
 can be slower on older ones.  To tweak the performances, the amount
 of time given to Jedi to compute type inference can be adjusted with
 ``c.IPCompleter.jedi_compute_type_timeout``. The objects whose type were not
 inferred will be shown as ``<unknown>``. Jedi can also be completely deactivated
 by using the ``c.Completer.use_jedi=False`` option.
 
 
 The old ``Completer.complete()`` API is waiting deprecation and should be
 replaced replaced by ``Completer.completions()`` in a near future. Feedback on
 the current state of the API and suggestions welcome.
 
 Python 3 only codebase
 ----------------------
 
 One of the large challenges in IPython 6.0 has been the adoption of a pure
 Python 3 codebase, which leads us to great length to upstream patches in pip,
 pypi and warehouse to make sure Python 2 system still upgrade to the latest
 compatible Python version compatible.
 
 We remind our Python 2 users that IPython 5 is still compatible with Python 2.7,
 still maintained and get regular releases. Using pip 9+, upgrading IPython will
 automatically upgrade to the latest version compatible with your system.
 
 .. warning::
 
   If you are on a system using an older version of pip on Python 2, pip may
   still install IPython 6.0 on your system, and IPython will refuse to start.
   You can fix this by upgrading pip, and reinstalling ipython, or forcing pip to
   install an earlier version: ``pip install 'ipython<6'``
 
 The ability to use only Python 3 on the code base of IPython  brings a number
 of advantage. Most of the newly written code make use of `optional function type
 annotation <https://www.python.org/dev/peps/pep-0484/>`_ leading to clearer code
 and better documentation.
 
 The total size of the repository has also decreased by about 1500 lines (for the 
 first time excluding the big split for 4.0). The decrease is potentially
 a bit more for the sour as some documents like this one are append only and
 are about 300 lines long.
 
 The removal as of Python2/Python3 shim layer has made the code quite clearer and
 more idiomatic in a number of location, and much friendlier to work with and
 understand. We hope to further embrace Python 3 capability in the next release
 cycle and introduce more of the Python 3 only idioms (yield from, kwarg only,
 general unpacking) in the code base of IPython, and see if we can take advantage
 of these as well to improve user experience with better error messages and
 hints.
 
 
 Configurable TerminalInteractiveShell, readline interface
 ---------------------------------------------------------
 
 IPython gained a new ``c.TerminalIPythonApp.interactive_shell_class`` option
 that allows customizing the class used to start the terminal frontend. This
 should allow a user to use custom interfaces, like reviving the former readline
 interface which is now a separate package not actively maintained by the core
 team. See the project to bring back the readline interface: `rlipython
 <https://github.com/ipython/rlipython>`_.
 
 This change will be backported to the IPython 5.x series.
 
 Miscs improvements
 ------------------
 
 
 - The :cellmagic:`capture` magic can now capture the result of a cell (from
   an expression on the last line), as well as printed and displayed output.
   :ghpull:`9851`.
 
 - Pressing Ctrl-Z in the terminal debugger now suspends IPython, as it already
   does in the main terminal prompt.
 
 - Autoreload can now reload ``Enum``. See :ghissue:`10232` and :ghpull:`10316`
 
 - IPython.display has gained a :any:`GeoJSON <IPython.display.GeoJSON>` object.
   :ghpull:`10288` and :ghpull:`10253`
 
 Functions Deprecated in 6.x Development cycle
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 - Loading extensions from ``ipython_extension_dir`` prints a warning that this
   location is pending deprecation. This should only affect users still having
   extensions installed with ``%install_ext`` which has been deprecated since
   IPython 4.0, and removed in 5.0. Extensions still present in
   ``ipython_extension_dir`` may shadow more recently installed versions using
   pip. It is thus recommended to clean ``ipython_extension_dir`` of any
   extension now available as a package.
 
 
 - ``IPython.utils.warn`` was deprecated in IPython 4.0, and has now been removed.
   instead of ``IPython.utils.warn`` inbuilt :any:`warnings` module is used.
 
 
 - The function `IPython.core.oinspect.py:call_tip` is unused, was marked as
   deprecated (raising a `DeprecationWarning`) and marked for later removal.
   :ghpull:`10104`
 
 Backward incompatible changes
 ------------------------------
 
 Functions Removed in 6.x Development cycle
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The following functions have been removed in the
 development cycle marked for Milestone 6.0.
 
 - ``IPython/utils/process.py`` - ``is_cmd_found``
 - ``IPython/utils/process.py`` - ``pycmd2argv``
 
 - The `--deep-reload` flag and the corresponding options to inject `dreload` or
   `reload` into the interactive namespace have been removed. You have to
   explicitly import `reload` from `IPython.lib.deepreload` to use it.
 
 - The :magic:`profile` used to print current IPython profile in use, and which
   was deprecated in IPython 2.0 does now raise a `DeprecationWarning` error when
   used. It is often confused with the :magic:`prun` and the deprecation remove
   should free up the ``profile`` name in future versions.