##// END OF EJS Templates
Merge pull request #2124 from bfroehle/use_alias_magic...
Merge pull request #2124 from bfroehle/use_alias_magic Add an API for registering magic aliases. Add a method `register_alias` to `MagicsManager` which can be used to register new magic aliases. Each magic alias is an instance of `MagicAlias`, a helper class whose `__call__` looks up the target of the alias (at call time) and dispatches the magic call. As a future benefit, this could be easily extended to allow for new aliases which contain some flags to pass to the function. For example, it would be easy to change the behavior to allow the creation of an `%ex` alias for `%edit -x`.

File last commit:

r7756:3b418859
r8023:a5beb59f merge
Show More
release.txt
53 lines | 2.1 KiB | text/plain | TextLexer
.. _releasing_ipython:
=================
Releasing IPython
=================
This section contains notes about the process that is used to release IPython.
Our release process is currently not very formal and could be improved.
Most of the release process is automated by the :file:`release` script in the
:file:`tools` directory. This is just a handy reminder for the release manager.
#. For writing release notes, this will cleanly show who contributed as author
of commits (get the previous release name from the tag list with ``git
tag``)::
git log --format="* %aN" $PREV_RELEASE... | sort -u
.. note::
use::
git log --format="%aN <%aE>" $PREV_RELEASE... | sort -u -f
To find duplicates and update :file:`.mailmap`
#. Run :file:`build_release`, which does all the file checking and building
that the real release script will do. This will let you do test
installations, check that the build procedure runs OK, etc. You may want to
disable a few things like multi-version RPM building while testing, because
otherwise the build takes really long.
#. Run the release script, which makes the tar.gz, eggs and Win32 .exe
installer. It posts them to the site and registers the release with PyPI.
#. Update the website with announcements and links to the updated changes.txt
in html form. Remember to put a short note on the news page of the site.
#. Drafting a short release announcement with i) highlights and ii) a link to
the html version of the :ref:`Whats new <whatsnew_index>` section of the
documentation.
#. Make sure that the released version of the docs is live on the site. For
this we are now using the gh-pages system:
- Make a static directory for the final copy of the release docs.
- Update the :file:`index.rst` file and run :file:`build_index.py` to update
the html version.
- Update the ``stable`` symlink to point to the released version.
- Run ``git add`` for all the new files and commit.
- Run ``git push`` to update the public version of the docs on gh-pages.
#. Celebrate!