Fixed #26020 -- Normalized header stylings in docs.

docs/releases/1.5.txt

@@ -85,7 +85,7 @@ offer an alpha release featuring 2.7 support, and Django 1.5 supports that alpha
 release.
 
 Python 3 support
-~~~~~~~~~~~~~~~~
+----------------
 
 Django 1.5 introduces support for Python 3 - specifically, Python
 3.2 and above. This comes in the form of a **single** codebase; you don't
@@ -122,7 +122,7 @@ What's new in Django 1.5
 ========================
 
 Configurable User model
-~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------
 
 In Django 1.5, you can now use your own model as the store for user-related
 data. If your project needs a username with more than 30 characters, or if
@@ -139,7 +139,7 @@ See the :ref:`documentation on custom User models <auth-custom-user>` for
 more details.
 
 Support for saving a subset of model's fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------
 
 The method :meth:`Model.save() <django.db.models.Model.save()>` has a new
 keyword argument ``update_fields``. By using this argument it is possible to
@@ -154,7 +154,7 @@ See the :meth:`Model.save() <django.db.models.Model.save()>` documentation for
 more details.
 
 Caching of related model instances
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------
 
 When traversing relations, the ORM will avoid re-fetching objects that were
 previously loaded. For example, with the tutorial's models::
@@ -174,7 +174,7 @@ is particularly helpful in combination with ``prefetch_related``.
 .. _explicit-streaming-responses:
 
 Explicit support for streaming responses
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------
 
 Before Django 1.5, it was possible to create a streaming response by passing
 an iterator to :class:`~django.http.HttpResponse`. But this was unreliable:
@@ -192,14 +192,14 @@ streaming responses and behave accordingly. See :ref:`response-middleware` for
 more information.
 
 ``{% verbatim %}`` template tag
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 To make it easier to deal with JavaScript templates which collide with Django's
 syntax, you can now use the :ttag:`verbatim` block tag to avoid parsing the
 tag's content.
 
 Retrieval of ``ContentType`` instances associated with proxy models
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------------------------
 
 The methods :meth:`ContentTypeManager.get_for_model() <django.contrib.contenttypes.models.ContentTypeManager.get_for_model()>`
 and :meth:`ContentTypeManager.get_for_models() <django.contrib.contenttypes.models.ContentTypeManager.get_for_models()>`
@@ -209,14 +209,14 @@ By passing ``False`` using this argument it is now possible to retrieve the
 associated with proxy models.
 
 New ``view`` variable in class-based views context
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------
 
 In all :doc:`generic class-based views </topics/class-based-views/index>`
 (or any class-based view inheriting from ``ContextMixin``), the context dictionary
 contains a ``view`` variable that points to the ``View`` instance.
 
 GeoDjango
-~~~~~~~~~
+---------
 
 * :class:`~django.contrib.gis.geos.LineString` and
   :class:`~django.contrib.gis.geos.MultiLineString` GEOS objects now support the
@@ -232,7 +232,7 @@ GeoDjango
   dropped.
 
 New tutorials
-~~~~~~~~~~~~~
+-------------
 
 Additions to the docs include a revamped :doc:`Tutorial 3</intro/tutorial03>`
 and a new :doc:`tutorial on testing</intro/tutorial05>`. A new section,
@@ -241,7 +241,7 @@ and a new :doc:`tutorial on testing</intro/tutorial05>`. A new section,
 :doc:`Writing your first patch for Django </intro/contributing>`.
 
 Minor features
-~~~~~~~~~~~~~~
+--------------
 
 Django 1.5 also includes several smaller improvements worth noting:
 
@@ -360,7 +360,7 @@ Backwards incompatible changes in 1.5
     backwards incompatible change.
 
 ``ALLOWED_HOSTS`` required in production
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------
 
 The new :setting:`ALLOWED_HOSTS` setting validates the request's ``Host``
 header and protects against host-poisoning attacks. This setting is now
@@ -370,7 +370,7 @@ required whenever :setting:`DEBUG` is ``False``, or else
 :setting:`full documentation<ALLOWED_HOSTS>` for the new setting.
 
 Managers on abstract models
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 Abstract models are able to define a custom manager, and that manager
 :ref:`will be inherited by any concrete models extending the abstract model
@@ -385,7 +385,7 @@ the abstract class, you should migrate that logic to a Python
 ``staticmethod`` or ``classmethod`` on the abstract class.
 
 Context in year archive class-based views
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------
 
 For consistency with the other date-based generic views,
 :class:`~django.views.generic.dates.YearArchiveView` now passes ``year`` in
@@ -397,7 +397,7 @@ year|date:"Y" }}``.
 calculated according to ``allow_empty`` and ``allow_future``.
 
 Context in year and month archive class-based views
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------
 
 :class:`~django.views.generic.dates.YearArchiveView` and
 :class:`~django.views.generic.dates.MonthArchiveView` were documented to
@@ -412,7 +412,7 @@ the documented order was restored. You may want to add (or remove) the
 ``date_list`` in descending order.
 
 Context in TemplateView
-~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------
 
 For consistency with the design of the other generic views,
 :class:`~django.views.generic.base.TemplateView` no longer passes a ``params``
@@ -420,7 +420,7 @@ dictionary into the context, instead passing the variables from the URLconf
 directly into the context.
 
 Non-form data in HTTP requests
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 :attr:`request.POST <django.http.HttpRequest.POST>` will no longer include data
 posted via HTTP requests with non form-specific content-types in the header.
@@ -432,7 +432,7 @@ should use the :attr:`request.body <django.http.HttpRequest.body>` attribute
 instead.
 
 :data:`~django.core.signals.request_finished` signal
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------
 
 Django used to send the :data:`~django.core.signals.request_finished` signal
 as soon as the view function returned a response. This interacted badly with
@@ -453,7 +453,7 @@ consider using :doc:`middleware </topics/http/middleware>` instead.
     connections to database and memcache servers.
 
 OPTIONS, PUT and DELETE requests in the test client
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------
 
 Unlike GET and POST, these HTTP methods aren't implemented by web browsers.
 Rather, they're used in APIs, which transfer data in various formats such as
@@ -475,7 +475,7 @@ client and set the ``content_type`` argument.
 .. _simplejson-incompatibilities:
 
 System version of ``simplejson`` no longer used
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------
 
 :ref:`As explained below <simplejson-deprecation>`, Django 1.5 deprecates
 ``django.utils.simplejson`` in favor of Python 2.6's built-in :mod:`json`
@@ -521,7 +521,7 @@ They recommend to use it from now on.
 .. _ticket #18023: https://code.djangoproject.com/ticket/18023#comment:10
 
 String types of hasher method parameters
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------
 
 If you have written a :ref:`custom password hasher <auth_password_storage>`,
 your ``encode()``, ``verify()`` or ``safe_summary()`` methods should accept
@@ -530,7 +530,7 @@ hashing methods need byte strings, you can use the
 :func:`~django.utils.encoding.force_bytes` utility to encode the strings.
 
 Validation of previous_page_number and next_page_number
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------------
 
 When using :doc:`object pagination </topics/pagination>`,
 the ``previous_page_number()`` and ``next_page_number()`` methods of the
@@ -540,7 +540,7 @@ It does check it now and raises an :exc:`~django.core.paginator.InvalidPage`
 exception when the number is either too low or too high.
 
 Behavior of autocommit database option on PostgreSQL changed
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------------
 
 PostgreSQL's autocommit option didn't work as advertised previously. It did
 work for single transaction block, but after the first block was left the
@@ -549,13 +549,13 @@ this is only a bug fix, it is worth checking your applications behavior if
 you are using PostgreSQL together with the autocommit option.
 
 Session not saved on 500 responses
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------
 
 Django's session middleware will skip saving the session data if the
 response's status code is 500.
 
 Email checks on failed admin login
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------
 
 Prior to Django 1.5, if you attempted to log into the admin interface and
 mistakenly used your email address instead of your username, the admin
@@ -567,13 +567,13 @@ affects the warning message that is displayed under one particular mode of
 login failure.
 
 Changes in tests execution
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------
 
 Some changes have been introduced in the execution of tests that might be
 backward-incompatible for some testing setups:
 
 Database flushing in ``django.test.TransactionTestCase``
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Previously, the test database was truncated *before* each test run in a
 :class:`~django.test.TransactionTestCase`.
@@ -583,7 +583,7 @@ always isolated from each other, :class:`~django.test.TransactionTestCase` will
 now reset the database *after* each test run instead.
 
 No more implicit DB sequences reset
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 :class:`~django.test.TransactionTestCase` tests used to reset primary key
 sequences automatically together with the database flushing actions described
@@ -598,7 +598,7 @@ be used to force the old behavior for :class:`~django.test.TransactionTestCase`
 that might need it.
 
 Ordering of tests
-^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~
 
 In order to make sure all ``TestCase`` code starts with a clean database,
 tests are now executed in the following order:
@@ -618,7 +618,7 @@ preserved after the execution of other tests. Such tests are already very
 fragile, and must now be changed to be able to run independently.
 
 `cleaned_data` dictionary kept for invalid forms
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------
 
 The :attr:`~django.forms.Form.cleaned_data` dictionary is now always present
 after form validation. When the form doesn't validate, it contains only the
@@ -628,7 +628,7 @@ presence or absence of the :attr:`~django.forms.Form.cleaned_data` attribute
 on the form.
 
 Behavior of ``syncdb`` with multiple databases
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------
 
 ``syncdb`` now queries the database routers to determine if content
 types (when :mod:`~django.contrib.contenttypes` is enabled) and permissions
@@ -642,7 +642,7 @@ them. See the docs on the :ref:`behavior of contrib apps with multiple
 databases <contrib_app_multiple_databases>` for more information.
 
 XML deserializer will not parse documents with a DTD
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------
 
 In order to prevent exposure to denial-of-service attacks related to external
 entity references and entity expansion, the XML model deserializer now refuses
@@ -652,7 +652,7 @@ cases where custom-created XML documents are passed to Django's model
 deserializer.
 
 Formsets default ``max_num``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 A (default) value of ``None`` for the ``max_num`` argument to a formset factory
 no longer defaults to allowing any number of forms in the formset. Instead, in
@@ -661,7 +661,7 @@ forms. This limit can be raised by explicitly setting a higher value for
 ``max_num``.
 
 Miscellaneous
-~~~~~~~~~~~~~
+-------------
 
 * :class:`django.forms.ModelMultipleChoiceField` now returns an empty
   ``QuerySet`` as the empty value instead of an empty list.
@@ -720,7 +720,7 @@ Features deprecated in 1.5
 ==========================
 
 ``django.contrib.localflavor``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 The localflavor contrib app has been split into separate packages.
 ``django.contrib.localflavor`` itself will be removed in Django 1.6,
@@ -732,7 +732,7 @@ dozen countries at this time; similar to translations, maintenance
 will be handed over to interested members of the community.
 
 ``django.contrib.markup``
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 The markup contrib module has been deprecated and will follow an accelerated
 deprecation schedule. Direct use of Python markup libraries or 3rd party tag
@@ -740,7 +740,7 @@ libraries is preferred to Django maintaining this functionality in the
 framework.
 
 ``AUTH_PROFILE_MODULE``
-~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------
 
 With the introduction of :ref:`custom User models <auth-custom-user>`, there is
 no longer any need for a built-in mechanism to store user profile data.
@@ -753,7 +753,7 @@ the ``AUTH_PROFILE_MODULE`` setting, and the
 the user profile model, should not be used any longer.
 
 Streaming behavior of :class:`~django.http.HttpResponse`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------------
 
 Django 1.5 deprecates the ability to stream a response by passing an iterator
 to :class:`~django.http.HttpResponse`. If you rely on this behavior, switch to
@@ -766,7 +766,7 @@ In Django 1.7 and above, the iterator will be consumed immediately by
 .. _simplejson-deprecation:
 
 ``django.utils.simplejson``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 Since Django 1.5 drops support for Python 2.5, we can now rely on the
 :mod:`json` module being available in Python's standard library, so we've
@@ -780,32 +780,32 @@ If you rely on features added to ``simplejson`` after it became Python's
 :mod:`json`, you should import ``simplejson`` explicitly.
 
 ``django.utils.encoding.StrAndUnicode``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------
 
 The ``django.utils.encoding.StrAndUnicode`` mix-in has been deprecated.
 Define a ``__str__`` method and apply the
 :func:`~django.utils.encoding.python_2_unicode_compatible` decorator instead.
 
 ``django.utils.itercompat.product``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------
 
 The ``django.utils.itercompat.product`` function has been deprecated. Use
 the built-in :func:`itertools.product` instead.
 
 ``cleanup`` management command
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 The ``cleanup`` management command has been deprecated and replaced by
 :djadmin:`clearsessions`.
 
 ``daily_cleanup.py`` script
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 The undocumented ``daily_cleanup.py`` script has been deprecated. Use the
 :djadmin:`clearsessions` management command instead.
 
 ``depth`` keyword argument in ``select_related``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------
 
 The ``depth`` keyword argument in
 :meth:`~django.db.models.query.QuerySet.select_related` has been deprecated.