Made cosmetic edits to docs/releases/6.0.txt.

docs/releases/6.0.txt

@@ -18,13 +18,13 @@ project.
 Python compatibility
 ====================
 
-Django 6.0 supports Python 3.12 and 3.13. We **highly recommend** and only
+Django 6.0 supports Python 3.12 and 3.13. We **highly recommend**, and only
-officially support the latest release of each series.
+officially support, the latest release of each series.
 
 The Django 5.2.x series is the last to support Python 3.10 and 3.11.
 
-Third-party library support for older version of Django
+Third-party library support for older versions of Django
-=======================================================
+========================================================
 
 Following the release of Django 6.0, we suggest that third-party app authors
 drop support for all versions of Django prior to 5.2. At that time, you should
@@ -75,28 +75,11 @@ guidance, see the :ref:`CSP security overview <security-csp>` and the
 :doc:`reference docs </ref/csp>`, which include details about decorators to
 override or disable policies on a per-view basis.
 
-Adoption of Python's modern email API
--------------------------------------
-
-Email handling in Django now uses Python's modern email API, introduced in
-Python 3.6. This API, centered around the
-:class:`email.message.EmailMessage` class, offers a cleaner and
-Unicode-friendly interface for composing and sending emails. It replaces use of
-Python's older legacy (``Compat32``) API, which relied on lower-level MIME
-classes (from :mod:`email.mime`) and required more manual handling of
-message structure and encoding.
-
-Notably, the return type of the :meth:`EmailMessage.message()
-<django.core.mail.EmailMessage.message>` method is now an instance of Python's
-:class:`email.message.EmailMessage`. This supports the same API as the
-previous ``SafeMIMEText`` and ``SafeMIMEMultipart`` return types, but is not an
-instance of those now-deprecated classes.
-
 Template Partials
 -----------------
 
 The :ref:`Django Template Language <template-language-intro>` now supports
-:ref:`template partials <template-partials>` , making it easier to encapsulate
+:ref:`template partials <template-partials>`, making it easier to encapsulate
 and reuse small named fragments within a template file. The new tags
 :ttag:`{% partialdef %} <partialdef>` and :ttag:`{% partial %} <partial>`
 define a partial and render it, respectively.
@@ -137,19 +120,33 @@ Once defined, tasks can be enqueued through a configured backend::
         message="Hello there!",
     )
 
-Backends are configured via the :setting:`TASKS` setting. Django provides
+Backends are configured via the :setting:`TASKS` setting. The :ref:`two
-two built-in backends, primarily for development and testing:
+built-in backends <task-available-backends>` included in this release are
+primarily intended for development and testing.
 
-* :class:`~django.tasks.backends.immediate.ImmediateBackend`: executes tasks
+Django handles task creation and queuing but does not provide a worker
-  immediately in the same process.
-* :class:`~django.tasks.backends.dummy.DummyBackend`: stores tasks without
-  running them, leaving results in the
-  :attr:`~django.tasks.TaskResultStatus.READY` state.
-
-Django only handles task creation and queuing; it does not provide a worker
 mechanism to run tasks. Execution must be managed by external infrastructure,
-such as a separate process or service. See :doc:`/topics/tasks` for an
+such as a separate process or service.
-overview, and the :doc:`Tasks reference </ref/tasks>` for API details.
+
+See :doc:`/topics/tasks` for an overview and the :doc:`Tasks reference
+</ref/tasks>` for API details.
+
+Adoption of Python's modern email API
+-------------------------------------
+
+Email handling in Django now uses Python's modern email API, introduced in
+Python 3.6. This API, centered around the
+:class:`email.message.EmailMessage` class, offers a cleaner and
+Unicode-friendly interface for composing and sending emails. It replaces use of
+Python's older legacy (``Compat32``) API, which relied on lower-level MIME
+classes (from :mod:`email.mime`) and required more manual handling of
+message structure and encoding.
+
+Notably, the return type of the :meth:`EmailMessage.message()
+<django.core.mail.EmailMessage.message>` method is now an instance of Python's
+:class:`email.message.EmailMessage`. This supports the same API as the
+previous ``SafeMIMEText`` and ``SafeMIMEMultipart`` return types, but is not an
+instance of those now-deprecated classes.
 
 Minor features
 --------------
@@ -343,13 +340,13 @@ backends.
 * ``DatabaseOperations.return_insert_columns()`` and
   ``DatabaseOperations.fetch_returned_insert_rows()`` methods are renamed to
   ``returning_columns()`` and ``fetch_returned_rows()``, respectively, to
-  denote they can be used in the context ``UPDATE … RETURNING`` statements as
+  denote they can be used in the context of ``UPDATE … RETURNING`` statements
-  well as ``INSERT … RETURNING``.
+  as well as ``INSERT … RETURNING``.
 
 * The ``DatabaseOperations.fetch_returned_insert_columns()`` method is removed
   and the ``fetch_returned_rows()`` method replacing
   ``fetch_returned_insert_rows()`` expects both a ``cursor`` and
-  ``returning_params`` to be provided just like
+  ``returning_params`` to be provided, just like
   ``fetch_returned_insert_columns()`` did.
 
 * If the database supports ``UPDATE … RETURNING`` statements, backends can set
@@ -402,7 +399,7 @@ Email
 ``DEFAULT_AUTO_FIELD`` setting now defaults to ``BigAutoField``
 ---------------------------------------------------------------
 
-Since Django 3.2 when the :setting:`DEFAULT_AUTO_FIELD` setting was added,
+Since Django 3.2, when the :setting:`DEFAULT_AUTO_FIELD` setting was added,
 the default :djadmin:`startproject` template's ``settings.py`` contained::
 
     DEFAULT_AUTO_FIELD = "django.db.models.BigAutoField"
@@ -418,11 +415,9 @@ In Django 6.0, :setting:`DEFAULT_AUTO_FIELD` now defaults to
 :class:`django.db.models.BigAutoField` and the aforementioned lines in the
 project and app templates are removed.
 
-Most projects shouldn't be affected since there has been a system check warning
+Most projects shouldn't be affected, since Django 3.2 has raised the system
-since Django 3.2 if a project doesn't set :setting:`DEFAULT_AUTO_FIELD`:
+check warning **models.W042** for projects that don't set
-
+:setting:`DEFAULT_AUTO_FIELD`.
-    **models.W042**: Auto-created primary key used when not defining a primary
-    key type, by default ``django.db.models.AutoField``.
 
 If you haven't dealt with this warning by now, add
 ``DEFAULT_AUTO_FIELD = 'django.db.models.AutoField'`` to your project's
@@ -581,7 +576,7 @@ to remove usage of these features.
 
 * The ``FORMS_URLFIELD_ASSUME_HTTPS`` transitional setting is removed.
 
-* The ``django.db.models.sql.datastructures.Join`` no longer fallback to
+* The ``django.db.models.sql.datastructures.Join`` no longer falls back to
   ``get_joining_columns()``.
 
 * The ``get_joining_columns()`` method of ``ForeignObject`` and
@@ -599,8 +594,8 @@ to remove usage of these features.
 * The ``get_prefetch_queryset()`` method of related managers and descriptors is
   removed.
 
-* ``get_prefetcher()`` and ``prefetch_related_objects()`` no longer fallback to
+* ``get_prefetcher()`` and ``prefetch_related_objects()`` no longer fall back
-  ``get_prefetch_queryset()``.
+  to ``get_prefetch_queryset()``.
 
 See :ref:`deprecated-features-5.1` for details on these changes, including how
 to remove usage of these features.
@@ -612,7 +607,7 @@ to remove usage of these features.
   methods are removed.
 
 * The undocumented ``django.utils.itercompat.is_iterable()`` function and the
-  ``django.utils.itercompat`` module is removed.
+  ``django.utils.itercompat`` module are removed.
 
 * The ``django.contrib.gis.geoip2.GeoIP2.coords()`` method is removed.