Added structure in the 1.6 release notes.

The backwards-incompatible changes section wasn't structured in sections
like it is in release notes for previous versions.

docs/releases/1.6.txt

@@ -165,57 +165,96 @@ Backwards incompatible changes in 1.6
     deprecation timeline for a given feature, its removal may appear as a
     backwards incompatible change.
 
-* Database-level autocommit is enabled by default in Django 1.6. While this
+New transaction management model
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Database-level autocommit is enabled by default in Django 1.6. While this
 doesn't change the general spirit of Django's transaction management, there
 are a few known backwards-incompatibities, described in the :ref:`transaction
-  management docs <transactions-upgrading-from-1.5>`. You should review your code
+management docs <transactions-upgrading-from-1.5>`. You should review your
-  to determine if you're affected.
+code to determine if you're affected.
 
-* In previous versions, database-level autocommit was only an option for
+In previous versions, database-level autocommit was only an option for
-  PostgreSQL, and it was disabled by default. This option is now
+PostgreSQL, and it was disabled by default. This option is now :ref:`ignored
-  :ref:`ignored <postgresql-autocommit-mode>`.
+<postgresql-autocommit-mode>` and can be removed.
 
-* The ``django.db.models.query.EmptyQuerySet`` can't be instantiated any more -
+Addition of ``QuerySet.datetimes()``
-  it is only usable as a marker class for checking if
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  :meth:`~django.db.models.query.QuerySet.none` has been called:
-  ``isinstance(qs.none(), EmptyQuerySet)``
 
-* :meth:`QuerySet.dates() <django.db.models.query.QuerySet.dates>` raises an
+When the :doc:`time zone support </topics/i18n/timezones>` added in Django 1.4
+was active, :meth:`QuerySet.dates() <django.db.models.query.QuerySet.dates>`
+lookups returned unexpected results, because the aggregation was performed in
+UTC. To fix this, Django 1.6 introduces a new API, :meth:`QuerySet.datetimes()
+<django.db.models.query.QuerySet.datetimes>`. This requires a few changes in
+your code.
+
+``QuerySet.dates()`` returns ``date`` objects
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+:meth:`QuerySet.dates() <django.db.models.query.QuerySet.dates>` now returns a
+list of :class:`~datetime.date`. It used to return a list of
+:class:`~datetime.datetime`.
+
+:meth:`QuerySet.datetimes() <django.db.models.query.QuerySet.datetimes>`
+returns a list of :class:`~datetime.datetime`.
+
+``QuerySet.dates()`` no longer usable on ``DateTimeField``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+:meth:`QuerySet.dates() <django.db.models.query.QuerySet.dates>` raises an
 error if it's used on :class:`~django.db.models.DateTimeField` when time
 zone support is active. Use :meth:`QuerySet.datetimes()
 <django.db.models.query.QuerySet.datetimes>` instead.
 
-* :meth:`QuerySet.dates() <django.db.models.query.QuerySet.dates>` returns a
+``date_hierarchy`` requires time zone definitions
-  list of :class:`~datetime.date`. It used to return a list of
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-  :class:`~datetime.datetime`.
 
-* The :attr:`~django.contrib.admin.ModelAdmin.date_hierarchy` feature of the
+The :attr:`~django.contrib.admin.ModelAdmin.date_hierarchy` feature of the
-  admin on a :class:`~django.db.models.DateTimeField` requires time zone
+admin now relies on :meth:`QuerySet.datetimes()
-  definitions in the database when :setting:`USE_TZ` is ``True``.
+<django.db.models.query.QuerySet.datetimes>` when it's used on a
-  :ref:`Learn more <database-time-zone-definitions>`.
+:class:`~django.db.models.DateTimeField`.
 
-* Accessing ``date_list`` in the context of a date-based generic view requires
+This requires time zone definitions in the database when :setting:`USE_TZ` is
-  time zone definitions in the database when the view is based on a
+``True``. :ref:`Learn more <database-time-zone-definitions>`.
-  :class:`~django.db.models.DateTimeField` and :setting:`USE_TZ` is ``True``.
-  :ref:`Learn more <database-time-zone-definitions>`.
 
-* Model fields named ``hour``, ``minute`` or ``second`` may clash with the new
+``date_list`` in generic views requires time zone definitions
-  lookups. Append an explicit :lookup:`exact` lookup if this is an issue.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-* When Django establishes a connection to the database, it sets up appropriate
+For the same reason, accessing ``date_list`` in the context of a date-based
+generic view requires time zone definitions in the database when the view is
+based on a :class:`~django.db.models.DateTimeField` and :setting:`USE_TZ` is
+``True``. :ref:`Learn more <database-time-zone-definitions>`.
+
+New lookups may clash with model fields
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Django 1.6 introduces ``hour``, ``minute``, and ``second`` lookups on
+:class:`~django.db.models.DateTimeField`. If you had model fields called
+``hour``, ``minute``, or ``second``, the new lookups will clash with you field
+names. Append an explicit :lookup:`exact` lookup if this is an issue.
+
+Persistent database connections
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Connection setup not repeated for each request
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When Django establishes a connection to the database, it sets up appropriate
 parameters, depending on the backend being used. Since `persistent database
 connections <persistent-database-connections>`_ are enabled by default in
 Django 1.6, this setup isn't repeated at every request any more. If you
-  modifiy parameters such as the connection's isolation level or time zone,
+modifiy parameters such as the connection's isolation level or time zone, you
-  you should either restore Django's defaults at the end of each request, or
+should either restore Django's defaults at the end of each request, force an
-  force an appropriate value at the beginning of each request.
+appropriate value at the beginning of each request, or disable persistent
+connections.
 
-* If your CSS/Javascript code used to access HTML input widgets by type, you
+Translations and comments in templates
-  should review it as ``type='text'`` widgets might be now output as
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  ``type='email'``, ``type='url'`` or ``type='number'`` depending on their
-  corresponding field type.
 
-* Extraction of translatable literals from templates with the
+Extraction of translations after comments
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Extraction of translatable literals from templates with the
 :djadmin:`makemessages` command now correctly detects i18n constructs when
 they are located after a ``{#`` / ``#}``-type comment on the same line. E.g.:
 
@@ -223,11 +262,13 @@ Backwards incompatible changes in 1.6
 
     {# A comment #}{% trans "This literal was incorrectly ignored. Not anymore" %}
 
-* (Related to the above item.) Validation of the placement of
+Location of translator comments
-  :ref:`translator-comments-in-templates` specified using ``{#`` / ``#}`` is now
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-  stricter. All translator comments not located at the end of their respective
+
-  lines in a template are ignored and a warning is generated by
+Validation of the placement of :ref:`translator-comments-in-templates`
-  :djadmin:`makemessages` when it finds them. E.g.:
+specified using ``{#`` / ``#}`` is now stricter. All translator comments not
+located at the end of their respective lines in a template are ignored and a
+warning is generated by :djadmin:`makemessages` when it finds them. E.g.:
 
   .. code-block:: html+django
 
@@ -235,12 +276,16 @@ Backwards incompatible changes in 1.6
     {{ title }}{# Translators: Extracted and associated with 'Welcome' below #}
     <h1>{% trans "Welcome" %}</h1>
 
-* The :doc:`comments </ref/contrib/comments/index>` app now uses a ``GenericIPAddressField``
+Storage of IP addresses in the comments app
-  for storing commenters' IP addresses, to support comments submitted from IPv6 addresses.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-  Until now, it stored them in an ``IPAddressField``, which is only meant to support IPv4.
+
-  When saving a comment made from an IPv6 address, the address would be silently truncated
+The :doc:`comments </ref/contrib/comments/index>` app now uses a
-  on MySQL databases, and raise an exception on Oracle.
+``GenericIPAddressField`` for storing commenters' IP addresses, to support
-  You will need to change the column type in your database to benefit from this change.
+comments submitted from IPv6 addresses. Until now, it stored them in an
+``IPAddressField``, which is only meant to support IPv4. When saving a comment
+made from an IPv6 address, the address would be silently truncated on MySQL
+databases, and raise an exception on Oracle. You will need to change the
+column type in your database to benefit from this change.
 
 For MySQL, execute this query on your project's database:
 
@@ -254,9 +299,22 @@ Backwards incompatible changes in 1.6
 
     ALTER TABLE DJANGO_COMMENTS MODIFY (ip_address VARCHAR2(39));
 
-  If you do not apply this change, the behaviour is unchanged: on MySQL, IPv6 addresses
+If you do not apply this change, the behaviour is unchanged: on MySQL, IPv6
-  are silently truncated; on Oracle, an exception is generated. No database
+addresses are silently truncated; on Oracle, an exception is generated. No
-  change is needed for SQLite or PostgreSQL databases.
+database change is needed for SQLite or PostgreSQL databases.
+
+Miscellaneous
+~~~~~~~~~~~~~
+
+* The ``django.db.models.query.EmptyQuerySet`` can't be instantiated any more -
+  it is only usable as a marker class for checking if
+  :meth:`~django.db.models.query.QuerySet.none` has been called:
+  ``isinstance(qs.none(), EmptyQuerySet)``
+
+* If your CSS/Javascript code used to access HTML input widgets by type, you
+  should review it as ``type='text'`` widgets might be now output as
+  ``type='email'``, ``type='url'`` or ``type='number'`` depending on their
+  corresponding field type.
 
 Features deprecated in 1.6
 ==========================