mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-09-18 06:59:12 +00:00
Code Issues 32 Releases Wiki Activity

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

Browse Source
This commit is contained in:
Natalia 2025-09-17 10:13:33 -03:00 committed by nessita
parent eae8cc4201
commit 154aa62e6f
1 changed files with 42 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

89
docs/releases/6.0.txt
View File

@ -18,13 +18,13 @@ project.
Python compatibility
====================
Django 6.0 supports Python 3.12 and 3.13. We **highly recommend** and only
officially support the latest release of each series.
Django 6.0 supports Python 3.12 and 3.13. We **highly recommend**, and only
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
two built-in backends, primarily for development and testing:
Backends are configured via the :setting:`TASKS` setting. The :ref:`two
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
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
Django handles task creation and queuing but 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
overview, and the :doc:`Tasks reference </ref/tasks>` for API details.
such as a separate process or service.
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
well as ``INSERT … RETURNING``.
denote they can be used in the context of ``UPDATE … RETURNING`` statements
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
since Django 3.2 if a project doesn'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``.
Most projects shouldn't be affected, since Django 3.2 has raised the system
check warning **models.W042** for projects that don't set
:setting:`DEFAULT_AUTO_FIELD`.
If you haven't dealt with this warning by now, add
``DEFAULT_AUTO_FIELD = 'django.db.models.AutoField'`` to your project's
@ -495,7 +490,7 @@ used parameters. Using positional arguments for these now emits a deprecation
warning and will raise a :exc:`TypeError` when the deprecation period ends.
* All *optional* parameters (``fail_silently`` and later) must be passed as
keyword arguments to :func:`get_connection`, :func:`mail_admins`,
keyword arguments to :func:`get_connection`, :func:`mail_admins`,
:func:`mail_managers`, :func:`send_mail`, and :func:`send_mass_mail`.
* All parameters must be passed as keyword arguments when creating an
@ -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_prefetch_queryset()``.
* ``get_prefetcher()`` and ``prefetch_related_objects()`` no longer fall back
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.