Merge remote-tracking branch 'core/master' into schema-alteration

Conflicts:
	django/db/models/fields/related.py

7 files changed, 240 insertions, 197 deletions

diff --git a/docs/internals/committers.txt b/docs/internals/committers.txt
index 6b9c7df14a..b56c8e469b 100644
--- a/docs/internals/committers.txt
+++ b/docs/internals/committers.txt
@@ -53,6 +53,7 @@ Journal-World`_ of Lawrence, Kansas, USA.
 .. _revolution systems: http://revsys.com/
 .. _wilson miner: http://wilsonminer.com/
 .. _heroku: http://heroku.com/
+.. _Rdio: http://rdio.com
 
 Current developers
 ==================
@@ -88,6 +89,23 @@ Malcolm Tredinnick
 
     *Malcolm passed away on March 17, 2013.*
 
+`Luke Plant`_
+    At University Luke studied physics and Materials Science and also
+    met `Michael Meeks`_ who introduced him to Linux and Open Source,
+    re-igniting an interest in programming.  Since then he has
+    contributed to a number of Open Source projects and worked
+    professionally as a developer.
+
+    Luke has contributed many excellent improvements to Django,
+    including database-level improvements, the CSRF middleware and
+    many unit tests.
+
+    Luke currently works for a church in Bradford, UK, and part-time
+    as a freelance developer.
+
+.. _luke plant: http://lukeplant.me.uk/
+.. _michael meeks: http://en.wikipedia.org/wiki/Michael_Meeks_(software)
+
 `Russell Keith-Magee`_
     Russell studied physics as an undergraduate, and studied neural networks for
     his PhD. His first job was with a startup in the defense industry developing
@@ -102,6 +120,42 @@ Malcolm Tredinnick
 
 .. _russell keith-magee: http://cecinestpasun.com/
 
+`James Bennett`_
+    James is Django's release manager, and also contributes to the
+    documentation and provide the occasional bugfix.
+
+    James came to Web development from philosophy when he discovered
+    that programmers get to argue just as much while collecting much
+    better pay. He lives in Lawrence, Kansas and previously worked at
+    World Online; currently, he's part of the Web development team at
+    Mozilla.
+
+    He `keeps a blog`_, and enjoys fine port and talking to his car.
+
+.. _james bennett: http://b-list.org/
+.. _keeps a blog: `james bennett`_
+
+`Gary Wilson`_
+    Gary starting contributing patches to Django in 2006 while developing Web
+    applications for `The University of Texas`_ (UT).  Since, he has made
+    contributions to the email and forms systems, as well as many other
+    improvements and code cleanups throughout the code base.
+
+    Gary is currently a developer and software engineering graduate student at
+    UT, where his dedication to spreading the ways of Python and Django never
+    ceases.
+
+    Gary lives in Austin, Texas, USA.
+
+.. _Gary Wilson: http://thegarywilson.com/
+.. _The University of Texas: http://www.utexas.edu/
+
+Matt Boersma
+    Matt is responsible for Django's Oracle support.
+
+Ian Kelly
+    Ian is also responsible for Django's support for Oracle.
+
 Joseph Kocherhans
     Joseph was the director of lead development at EveryBlock and previously
     developed at the Lawrence Journal-World. He is treasurer of the `Django
@@ -119,28 +173,11 @@ Joseph Kocherhans
 .. _django software foundation: https://www.djangoproject.com/foundation/
 .. _charango: http://en.wikipedia.org/wiki/Charango
 
-`Luke Plant`_
-    At University Luke studied physics and Materials Science and also
-    met `Michael Meeks`_ who introduced him to Linux and Open Source,
-    re-igniting an interest in programming.  Since then he has
-    contributed to a number of Open Source projects and worked
-    professionally as a developer.
-
-    Luke has contributed many excellent improvements to Django,
-    including database-level improvements, the CSRF middleware and
-    many unit tests.
-
-    Luke currently works for a church in Bradford, UK, and part-time
-    as a freelance developer.
-
-.. _luke plant: http://lukeplant.me.uk/
-.. _michael meeks: http://en.wikipedia.org/wiki/Michael_Meeks_(software)
-
 `Brian Rosner`_
-    Brian is currently the tech lead at Eldarion_ managing and developing
+    Brian is the Chief Architect at Eldarion_ managing and developing
     Django / Pinax_ based Web sites. He enjoys learning more about programming
     languages and system architectures and contributing to open source
-    projects. Brian is the host of the `Django Dose`_ podcasts.
+    projects.
 
     Brian helped immensely in getting Django's "newforms-admin" branch finished
     in time for Django 1.0; he's now a full committer, continuing to improve on
@@ -150,24 +187,8 @@ Joseph Kocherhans
 
 .. _brian rosner: http://brosner.com/
 .. _eldarion: http://eldarion.com/
-.. _django dose: http://djangodose.com/
 .. _pinax: http://pinaxproject.com/
 
-`Gary Wilson`_
-    Gary starting contributing patches to Django in 2006 while developing Web
-    applications for `The University of Texas`_ (UT).  Since, he has made
-    contributions to the email and forms systems, as well as many other
-    improvements and code cleanups throughout the code base.
-
-    Gary is currently a developer and software engineering graduate student at
-    UT, where his dedication to spreading the ways of Python and Django never
-    ceases.
-
-    Gary lives in Austin, Texas, USA.
-
-.. _Gary Wilson: http://thegarywilson.com/
-.. _The University of Texas: http://www.utexas.edu/
-
 Justin Bronn
     Justin Bronn is a computer scientist and attorney specializing
     in legal topics related to intellectual property and spatial law.
@@ -222,7 +243,7 @@ Karen Tracey
 .. _James Tauber: http://jtauber.com/
 
 `Alex Gaynor`_
-    Alex is a software engineer working at Rdio_. He found Django in 2007 and
+    Alex is a software engineer working at Rackspace_. He found Django in 2007 and
     has been addicted ever since he found out you don't need to write out your
     forms by hand. He has a small obsession with compilers.  He's contributed
     to the ORM, forms, admin, and other components of Django.
@@ -230,7 +251,16 @@ Karen Tracey
     Alex lives in San Francisco, CA, USA.
 
 .. _Alex Gaynor: http://alexgaynor.net
-.. _Rdio: http://rdio.com
+.. _Rackspace: http://www.rackspace.com
+
+`Simon Meers`_
+    Simon discovered Django 0.96 during his Computer Science PhD research and
+    has been developing with it full-time ever since. His core code
+    contributions are mostly in Django's admin application.
+
+    Simon works as a freelance developer based in Wollongong, Australia.
+
+.. _Simon Meers: http://simonmeers.com/
 
 `Andrew Godwin`_
     Andrew is a freelance Python developer and tinkerer, and has been
@@ -265,6 +295,18 @@ Ramiro Morales
 
     Ramiro lives in Córdoba, Argentina.
 
+`Gabriel Hurley`_
+    Gabriel has been working with Django since 2008, shortly after the 1.0
+    release. Convinced by his business partner that Python and Django were the
+    right direction for the company, he couldn't have been more happy with the
+    decision. His contributions range across many areas in Django, but years of
+    copy-editing and an eye for detail lead him to be particularly at home
+    while working on Django's documentation.
+
+    Gabriel works as a web developer in Berkeley, CA, USA.
+
+.. _gabriel hurley: http://strikeawe.com/
+
 `Chris Beaven`_
     Chris has been submitting patches and suggesting crazy ideas for Django
     since early 2006. An advocate for community involvement and a long-term
@@ -290,6 +332,13 @@ Honza Král
 
 .. _Whiskey Media: http://www.whiskeymedia.com/
 
+Tim Graham
+    When exploring Web frameworks for an independent study project in the fall
+    of 2008, Tim discovered Django and was lured to it by the documentation.
+    He enjoys contributing to the docs because they're awesome.
+
+    Tim works as a software engineer and lives in Philadelphia, PA, USA.
+
 `Idan Gazit`_
     As a self-professed design geek, Idan was initially attracted to Django
     sometime between magic-removal and queryset-refactor. Formally trained
@@ -439,6 +488,18 @@ Jeremy Dunck
 .. _Ultimate Frisbee: http://www.montrealultimate.ca
 .. _Reptiletech: http://www.reptiletech.com
 
+Donald Stufft
+    Donald found Python and Django in 2007 while trying to find a language,
+    and web framework that he really enjoyed using after many years of PHP. He
+    fell in love with the beauty of Python and the way Django made tasks simple
+    and easy. His contributions to Django focus primarily on ensuring that it
+    is and remains a secure web framework.
+
+    Donald currently works at `Nebula Inc`_ as a Software Engineer for their
+    security team and lives in the Greater Philadelphia Area.
+
+.. _Nebula Inc: https://www.nebula.com/
+
 `Daniel Lindsley`_
     Pythonista since 2003, Djangonaut since 2006. Daniel started with Django
     just after the v0.90 release (back when ``Manipulators`` looked good) & fell
@@ -453,56 +514,6 @@ Jeremy Dunck
 .. _`Daniel Lindsley`: http://toastdriven.com/
 .. _`Amazon Web Services`: https://aws.amazon.com/
 
-`James Bennett`_
-    James is Django's release manager, and also contributes to the
-    documentation and provide the occasional bugfix.
-
-    James came to Web development from philosophy when he discovered
-    that programmers get to argue just as much while collecting much
-    better pay. He lives in Lawrence, Kansas and previously worked at
-    World Online; currently, he's part of the Web development team at
-    Mozilla.
-
-    He `keeps a blog`_, and enjoys fine port and talking to his car.
-
-.. _james bennett: http://b-list.org/
-.. _keeps a blog: `james bennett`_
-
-Ian Kelly
-    Ian is responsible for Django's support for Oracle.
-
-Matt Boersma
-    Matt is also responsible for Django's Oracle support.
-
-`Simon Meers`_
-    Simon discovered Django 0.96 during his Computer Science PhD research and
-    has been developing with it full-time ever since. His core code
-    contributions are mostly in Django's admin application. He is also helping
-    to improve Django's documentation.
-
-    Simon works as a freelance developer based in Wollongong, Australia.
-
-.. _simon meers: http://simonmeers.com/
-
-`Gabriel Hurley`_
-    Gabriel has been working with Django since 2008, shortly after the 1.0
-    release. Convinced by his business partner that Python and Django were the
-    right direction for the company, he couldn't have been more happy with the
-    decision. His contributions range across many areas in Django, but years of
-    copy-editing and an eye for detail lead him to be particularly at home
-    while working on Django's documentation.
-
-    Gabriel works as a web developer in Berkeley, CA, USA.
-
-.. _gabriel hurley: http://strikeawe.com/
-
-Tim Graham
-    When exploring Web frameworks for an independent study project in the fall
-    of 2008, Tim discovered Django and was lured to it by the documentation.
-    He enjoys contributing to the docs because they're awesome.
-
-    Tim works as a software engineer and lives in Philadelphia, PA, USA.
-
 Marc Tamlyn
     Marc started life on the web using Django 1.2 back in 2010, and has never
     looked back. He was involved with rewriting the class based view
@@ -515,18 +526,6 @@ Marc Tamlyn
 .. _CCBV: http://ccbv.co.uk/
 .. _Incuna Ltd: http://incuna.com/
 
-Donald Stufft
-    Donald found Python and Django in 2007 while trying to find a language,
-    and web framework that he really enjoyed using after many years of PHP. He
-    fell in love with the beauty of Python and the way Django made tasks simple
-    and easy. His contributions to Django focus primarily on ensuring that it
-    is and remains a secure web framework.
-
-    Donald currently works at `Nebula Inc`_ as a Software Engineer for their
-    security team and lives in the Greater Philadelphia Area.
-
-.. _Nebula Inc: https://www.nebula.com/
-
 Developers Emeritus
 ===================
 
diff --git a/docs/internals/contributing/triaging-tickets.txt b/docs/internals/contributing/triaging-tickets.txt
index bc6148ca46..43b799ed51 100644
--- a/docs/internals/contributing/triaging-tickets.txt
+++ b/docs/internals/contributing/triaging-tickets.txt
@@ -349,8 +349,9 @@ Then, you can help out by:
 
 * Closing "Unreviewed" tickets as "invalid", "worksforme" or "duplicate."
 
-* Closing "Unreviewed" tickets as "needsinfo" when they're feature requests
-  requiring a discussion on `django-developers`_.
+* Closing "Unreviewed" tickets as "needsinfo" when the description is too
+  sparse to be actionnable, or when they're feature requests requiring a
+  discussion on `django-developers`_.
 
 * Correcting the "Needs tests", "Needs documentation", or "Has patch"
   flags for tickets where they are incorrectly set.
diff --git a/docs/internals/contributing/writing-code/unit-tests.txt b/docs/internals/contributing/writing-code/unit-tests.txt
index f56bf1cdeb..0737b84888 100644
--- a/docs/internals/contributing/writing-code/unit-tests.txt
+++ b/docs/internals/contributing/writing-code/unit-tests.txt
@@ -27,15 +27,13 @@ Quickstart
 Running the tests requires a Django settings module that defines the
 databases to use. To make it easy to get started, Django provides a
 sample settings module that uses the SQLite database. To run the tests
-with this sample ``settings`` module, ``cd`` into the Django
-``tests/`` directory and run:
+with this sample ``settings`` module:
 
 .. code-block:: bash
 
-    ./runtests.py --settings=test_sqlite
-
-If you get an ``ImportError: No module named django.contrib`` error,
-you need to add your install of Django to your ``PYTHONPATH``.
+    git clone git@github.com:django/django.git django-repo
+    cd django-repo/tests
+    PYTHONPATH=..:$PYTHONPATH python ./runtests.py --settings=test_sqlite
 
 .. _running-unit-tests-settings:
 
@@ -47,14 +45,10 @@ SQLite. If you want to test behavior using a different database (and
 if you're proposing patches for Django, it's a good idea to test
 across databases), you may need to define your own settings file.
 
-To run the tests with different settings, ``cd`` to the ``tests/`` directory
-and type:
-
-.. code-block:: bash
-
-    ./runtests.py --settings=path.to.django.settings
+To run the tests with different settings, ensure that the module is on your
+``PYTHONPATH`` and pass the module with ``--settings``.
 
-The :setting:`DATABASES` setting in this test settings module needs to define
+The :setting:`DATABASES` setting in any test settings module needs to define
 two databases:
 
 * A ``default`` database. This database should use the backend that
diff --git a/docs/internals/deprecation.txt b/docs/internals/deprecation.txt
index 774de2a2fd..45f82b49e6 100644
--- a/docs/internals/deprecation.txt
+++ b/docs/internals/deprecation.txt
@@ -373,6 +373,7 @@ these changes.
 
 * The following private APIs will be removed:
 
+  - ``django.db.backend``
   - ``django.db.close_connection()``
   - ``django.db.backends.creation.BaseDatabaseCreation.set_autocommit()``
   - ``django.db.transaction.is_managed()``
@@ -385,10 +386,15 @@ these changes.
   ``django.test.simple.DjangoTestSuiteRunner`` will be removed. Instead use
   ``django.test.runner.DiscoverRunner``.
 
-* The module ``django.test._doctest`` and the classes
-  ``django.test.testcases.DocTestRunner`` and
-  ``django.test.testcases.OutputChecker`` will be removed. Instead use the
-  doctest module from the Python standard library.
+* The module ``django.test._doctest`` will be removed. Instead use the doctest
+  module from the Python standard library.
+
+* The ``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting will be removed.
+
+* Usage of the hard-coded *Hold down "Control", or "Command" on a Mac, to select
+  more than one.* string to override or append to user-provided ``help_text`` in
+  forms for ManyToMany model fields will not be performed by Django anymore
+  either at the model or forms layer.
 
 2.0
 ---
diff --git a/docs/internals/git.txt b/docs/internals/git.txt
index 2b1a279d89..3904ff83d4 100644
--- a/docs/internals/git.txt
+++ b/docs/internals/git.txt
@@ -35,8 +35,9 @@ The Git repository includes several `branches`_:
   the next packaged release of Django. This is where most development
   activity is focused.
 
-* ``stable/A.B.x`` are the maintenance branches. They are used to support
-  older versions of Django.
+* ``stable/A.B.x`` are the branches where release preparation work happens.
+  They are also used for support and bugfix releases which occur as necessary
+  after the initial release of a major or minor version.
 
 * ``soc20XX/<project>`` branches were used by students who worked on Django
   during the 2009 and 2010 Google Summer of Code programs.
@@ -83,13 +84,50 @@ coding style and how to generate and submit a patch.
 Other branches
 ==============
 
-Django uses branches for two main purposes:
+Django uses branches to prepare for releases of Django (whether they be
+:term:`major <Major release>`, :term:`minor <Minor release>`, or
+:term:`micro <Micro release>`).
 
-1. Development of major or experimental features, to keep them from
-   affecting progress on other work in master.
+In the past when Django was hosted on Subversion, branches were also used for
+feature development. Now Django is hosted on Git and feature development is
+done on contributor's forks, but the Subversion feature branches remain in Git
+for historical reference.
 
-2. Security and bugfix support for older releases of Django, during
-   their support lifetimes.
+Stable branches
+---------------
+
+These branches can be found in the repository as ``stable/A.B.x``
+branches and will be created right after the first alpha is tagged.
+
+For example, immediately after *Django 1.5 alpha 1* was tagged, the branch
+``stable/1.5.x`` was created and all further work on preparing the code for the
+final 1.5 release was done there.
+
+These branches also provide limited bugfix support for the most recent released
+version of Django and security support for the two most recently-released
+versions of Django.
+
+For example, after the release of Django 1.5, the branch ``stable/1.5.x``
+receives only fixes for security and critical stability bugs, which are
+eventually released as Django 1.5.1 and so on, ``stable/1.4.x`` receives only
+security fixes, and ``stable/1.3.x`` no longer receives any updates.
+
+.. admonition:: Historical information
+
+    This policy for handling ``stable/A.B.x`` branches was adopted starting
+    with the Django 1.5 release cycle.
+
+    Previously, these branches weren't created until right after the releases
+    and the stabilization work occurred on the main repository branch. Thus,
+    no new features development work for the next release of Django could be
+    committed until the final release happened.
+
+    For example, shortly after the release of Django 1.3 the branch
+    ``stable/1.3.x`` was created. Official support for that release has expired,
+    and so it no longer receives direct maintenance from the Django project.
+    However, that and all other similarly named branches continue to exist and
+    interested community members have occasionally used them to provide
+    unofficial support for old Django releases.
 
 Feature-development branches
 ----------------------------
@@ -203,30 +241,6 @@ All of the above-mentioned branches now reside in ``attic``.
 Finally, the repository contains ``soc2009/xxx`` and ``soc2010/xxx`` feature
 branches, used for Google Summer of Code projects.
 
-Support and bugfix branches
----------------------------
-
-In addition to fixing bugs in current master, the Django project provides
-official bugfix support for the most recent released version of Django, and
-security support for the two most recently-released versions of Django.
-
-This support is provided via branches in which the necessary bug or security
-fixes are applied; the branches are then used as the basis for issuing bugfix
-or security releases.
-
-These branches can be found in the repository as ``stable/A.B.x``
-branches, and new branches will be created there after each new Django
-release.
-
-For example, shortly after the release of Django 1.0, the branch
-``stable/1.0.x`` was created to receive bug fixes, and shortly after the
-release of Django 1.1 the branch ``stable/1.1.x`` was created.
-
-Official support for the above mentioned releases has expired, and so they no
-longer receive direct maintenance from the Django project. However, the
-branches continue to exist and interested community members have occasionally
-used them to provide unofficial support for old Django releases.
-
 Tags
 ====
 
diff --git a/docs/internals/howto-release-django.txt b/docs/internals/howto-release-django.txt
index fd985ddafc..5bda2e8add 100644
--- a/docs/internals/howto-release-django.txt
+++ b/docs/internals/howto-release-django.txt
@@ -183,13 +183,46 @@ OK, this is the fun part, where we actually push out a release!
         $ md5sum dist/Django-*
         $ sha1sum dist/Django-*
 
-   *FIXME: perhaps we should switch to sha256?*
-
 #. Create a "checksums" file containing the hashes and release information.
-   You can start with `a previous checksums file`__ and replace the
-   dates, keys, links, and checksums. *FIXME: make a template file.*
+   Start with this template and insert the correct version, date, release URL
+   and checksums::
+
+    This file contains MD5 and SHA1 checksums for the source-code tarball
+    of Django <<VERSION>>, released <<DATE>>.
+
+    To use this file, you will need a working install of PGP or other
+    compatible public-key encryption software. You will also need to have
+    the Django release manager's public key in your keyring; this key has
+    the ID ``0x3684C0C08C8B2AE1`` and can be imported from the MIT
+    keyserver. For example, if using the open-source GNU Privacy Guard
+    implementation of PGP::
+
+        gpg --keyserver pgp.mit.edu --recv-key 0x3684C0C08C8B2AE1
+
+    Once the key is imported, verify this file::
+
+        gpg --verify <<THIS FILENAME>>
+
+    Once you have verified this file, you can use normal MD5 and SHA1
+    checksumming applications to generate the checksums of the Django
+    package and compare them to the checksums listed below.
+
+
+    Release package:
+    ================
+
+    Django <<VERSION>>: https://www.djangoproject.com/m/releases/<<URL>>
+
+
+    MD5 checksum:
+    =============
+
+    MD5(<<RELEASE TAR.GZ FILENAME>>)= <<MD5SUM>>
+
+    SHA1 checksum:
+    ==============
 
-   __ https://www.djangoproject.com/m/pgp/Django-1.5b1.checksum.txt
+    SHA1(<<RELEASE TAR.GZ FILENAME>>)= <<SHA1SUM>>
 
 #. Sign the checksum file (``gpg --clearsign
    Django-<version>.checksum.txt``). This generates a signed document,
@@ -268,8 +301,7 @@ Now you're ready to actually put the release out there. To do this:
    of the docs by flipping the ``is_default`` flag to ``True`` on the
    appropriate ``DocumentRelease`` object in the ``docs.djangoproject.com``
    database (this will automatically flip it to ``False`` for all
-   others). *FIXME: I had to do this via fab managepy:shell,docs but we should
-   probably make it possible to do via the admin.*
+   others); you can do this using the site's admin.
 
 #. Post the release announcement to the django-announce,
    django-developers and django-users mailing lists. This should
@@ -289,7 +321,8 @@ You're almost done! All that's left to do now is:
    ``stable/1.?.x`` git branch), you'll want to create a new
    ``DocumentRelease`` object in the ``docs.djangoproject.com`` database for
    the new version's docs, and update the ``docs/fixtures/doc_releases.json``
-   JSON fixture. *FIXME: what is the purpose of maintaining this fixture?*
+   JSON fixture, so people without access to the production DB can still
+   run an up-to-date copy of the docs site.
 
 #. Add the release in `Trac's versions list`_ if necessary. Not all versions
    are declared; take example on previous releases.
diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt
index 29ce3914b4..2003e79079 100644
--- a/docs/internals/release-process.txt
+++ b/docs/internals/release-process.txt
@@ -39,49 +39,45 @@ issued from those branches.
 For more information about how the Django project issues new releases for
 security purposes, please see :doc:`our security policies <security>`.
 
-Major releases
---------------
+.. glossary::
 
-Major releases (1.0, 2.0, etc.) will happen very infrequently (think "years",
-not "months"), and may represent major, sweeping changes to Django.
+  Major release
+    Major releases (1.0, 2.0, etc.) will happen very infrequently (think "years",
+    not "months"), and may represent major, sweeping changes to Django.
 
-Minor releases
---------------
+  Minor release
+    Minor release (1.5, 1.6, etc.) will happen roughly every nine months -- see
+    `release process`_, below for details. These releases will contain new
+    features, improvements to existing features, and such.
 
-Minor release (1.5, 1.6, etc.) will happen roughly every nine months -- see
-`release process`_, below for details. These releases will contain new
-features, improvements to existing features, and such.
+    .. _internal-release-deprecation-policy:
 
-.. _internal-release-deprecation-policy:
+    A minor release may deprecate certain features from previous releases. If a
+    feature is deprecated in version ``A.B``, it will continue to work in versions
+    ``A.B`` and  ``A.B+1`` but raise warnings. It will be removed in version
+    ``A.B+2``.
 
-A minor release may deprecate certain features from previous releases. If a
-feature is deprecated in version ``A.B``, it will continue to work in versions
-``A.B`` and  ``A.B+1`` but raise warnings. It will be removed in version
-``A.B+2``.
+    So, for example, if we decided to start the deprecation of a function in
+    Django 1.5:
 
-So, for example, if we decided to start the deprecation of a function in
-Django 1.5:
+    * Django 1.5 will contain a backwards-compatible replica of the function which
+      will raise a ``PendingDeprecationWarning``. This warning is silent by
+      default; you can turn on display of these warnings with the ``-Wd`` option
+      of Python.
 
-* Django 1.5 will contain a backwards-compatible replica of the function which
-  will raise a ``PendingDeprecationWarning``. This warning is silent by
-  default; you can turn on display of these warnings with the ``-Wd`` option
-  of Python.
+    * Django 1.6 will contain the backwards-compatible replica, but the warning
+      will be promoted to a full-fledged ``DeprecationWarning``. This warning is
+      *loud* by default, and will likely be quite annoying.
 
-* Django 1.6 will contain the backwards-compatible replica, but the warning
-  will be promoted to a full-fledged ``DeprecationWarning``. This warning is
-  *loud* by default, and will likely be quite annoying.
+    * Django 1.7 will remove the feature outright.
 
-* Django 1.7 will remove the feature outright.
+  Micro release
+    Micro releases (1.5.1, 1.6.2, 1.6.1, etc.) will be issued as needed, often to
+    fix security issues.
 
-Micro releases
---------------
-
-Micro releases (1.5.1, 1.6.2, 1.6.1, etc.) will be issued as needed, often to
-fix security issues.
-
-These releases will be 100% compatible with the associated minor release, unless
-this is impossible for security reasons. So the answer to "should I upgrade to
-the latest micro release?" will always be "yes."
+    These releases will be 100% compatible with the associated minor release, unless
+    this is impossible for security reasons. So the answer to "should I upgrade to
+    the latest micro release?" will always be "yes."
 
 .. _backwards-compatibility-policy:
 
@@ -126,15 +122,15 @@ Django 1.6 and 1.7. At this point in time:
 
 * Features will be added to development master, to be released as Django 1.7.
 
-* Critical bug fixes will be applied to the ``stable/1.6.X`` branch, and
+* Critical bug fixes will be applied to the ``stable/1.6.x`` branch, and
   released as 1.6.1, 1.6.2, etc.
 
-* Security fixes will be applied to ``master``, to the ``stable/1.6.X``
-  branch, and to the ``stable/1.5.X`` branch. They will trigger the release of
+* Security fixes will be applied to ``master``, to the ``stable/1.6.x``
+  branch, and to the ``stable/1.5.x`` branch. They will trigger the release of
   ``1.6.1``, ``1.5.1``, etc.
 
 * Documentation fixes will be applied to master, and, if easily backported, to
-  the ``1.6.X`` branch. Bugfixes may also be backported.
+  the ``1.6.x`` branch. Bugfixes may also be backported.
 
 .. _release-process:
 
@@ -193,9 +189,9 @@ Phase two will culminate with an alpha release. At this point, the
 Phase three: bugfixes
 ~~~~~~~~~~~~~~~~~~~~~
 
-The last third of a release is spent fixing bugs -- no new features will be
-accepted during this time. We'll try to release a beta release after one month
-and a release candidate after two months.
+The last third of a release cycle is spent fixing bugs -- no new features will
+be accepted during this time. We'll try to release a beta release after one
+month and a release candidate after two months.
 
 The release candidate marks the string freeze, and it happens at least two
 weeks before the final release. After this point, new translatable strings