Alphabetized a few sections in the 1.9 release notes + made a few tweaks.
This commit is contained in:
parent
15ce1a735c
commit
bed83e0fb5
|
@ -6,9 +6,9 @@ Welcome to Django 1.9!
|
||||||
|
|
||||||
These release notes cover the `new features`_, as well as some `backwards
|
These release notes cover the `new features`_, as well as some `backwards
|
||||||
incompatible changes`_ you'll want to be aware of when upgrading from Django
|
incompatible changes`_ you'll want to be aware of when upgrading from Django
|
||||||
1.8 or older versions. We've :ref:`dropped some features
|
1.8 or older versions. We've :ref:`dropped some features<removed-features-1.9>`
|
||||||
<deprecation-removed-in-1.9>` that have reached the end of their deprecation
|
that have reached the end of their deprecation cycle, and we've `begun the
|
||||||
cycle, and we've `begun the deprecation process for some features`_.
|
deprecation process for some features`_.
|
||||||
|
|
||||||
.. _`new features`: `What's new in Django 1.9`_
|
.. _`new features`: `What's new in Django 1.9`_
|
||||||
.. _`backwards incompatible changes`: `Backwards incompatible changes in 1.9`_
|
.. _`backwards incompatible changes`: `Backwards incompatible changes in 1.9`_
|
||||||
|
@ -18,9 +18,11 @@ cycle, and we've `begun the deprecation process for some features`_.
|
||||||
Python compatibility
|
Python compatibility
|
||||||
====================
|
====================
|
||||||
|
|
||||||
Like Django 1.8, Django 1.9 requires Python 2.7 or above, though we
|
Django 1.9 requires Python 2.7, 3.4, or 3.5. We **highly recommend** and only
|
||||||
**highly recommend** the latest minor release. We've dropped support for
|
officially support the latest release of each series.
|
||||||
Python 3.2 and 3.3, and added support for Python 3.5.
|
|
||||||
|
Since Django 1.8, we've dropped support for Python 3.2 and 3.3, and added
|
||||||
|
support for Python 3.5.
|
||||||
|
|
||||||
What's new in Django 1.9
|
What's new in Django 1.9
|
||||||
========================
|
========================
|
||||||
|
@ -197,8 +199,8 @@ Minor features
|
||||||
|
|
||||||
* ``AbstractBaseUser`` and ``BaseUserManager`` were moved to a new
|
* ``AbstractBaseUser`` and ``BaseUserManager`` were moved to a new
|
||||||
``django.contrib.auth.base_user`` module so that they can be imported without
|
``django.contrib.auth.base_user`` module so that they can be imported without
|
||||||
including ``django.contrib.auth`` in :setting:`INSTALLED_APPS` (this raised
|
including ``django.contrib.auth`` in :setting:`INSTALLED_APPS` (doing so
|
||||||
a deprecation warning in older versions and is no longer supported in
|
raised a deprecation warning in older versions and is no longer supported in
|
||||||
Django 1.9).
|
Django 1.9).
|
||||||
|
|
||||||
* The permission argument of
|
* The permission argument of
|
||||||
|
@ -320,6 +322,26 @@ Cache
|
||||||
headers (added ``no-cache, no-store, must-revalidate`` to ``Cache-Control``)
|
headers (added ``no-cache, no-store, must-revalidate`` to ``Cache-Control``)
|
||||||
to better prevent caching.
|
to better prevent caching.
|
||||||
|
|
||||||
|
CSRF
|
||||||
|
^^^^
|
||||||
|
|
||||||
|
* The request header's name used for CSRF authentication can be customized
|
||||||
|
with :setting:`CSRF_HEADER_NAME`.
|
||||||
|
|
||||||
|
* The CSRF referer header is now validated against the
|
||||||
|
:setting:`CSRF_COOKIE_DOMAIN` setting if set. See :ref:`how-csrf-works` for
|
||||||
|
details.
|
||||||
|
|
||||||
|
* The new :setting:`CSRF_TRUSTED_ORIGINS` setting provides a way to allow
|
||||||
|
cross-origin unsafe requests (e.g. ``POST``) over HTTPS.
|
||||||
|
|
||||||
|
Database backends
|
||||||
|
^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
* The PostgreSQL backend (``django.db.backends.postgresql_psycopg2``) is also
|
||||||
|
available as ``django.db.backends.postgresql``. The old name will continue to
|
||||||
|
be available for backwards compatibility.
|
||||||
|
|
||||||
Email
|
Email
|
||||||
^^^^^
|
^^^^^
|
||||||
|
|
||||||
|
@ -539,61 +561,6 @@ Models
|
||||||
* Added a new model field check that makes sure
|
* Added a new model field check that makes sure
|
||||||
:attr:`~django.db.models.Field.default` is a valid value.
|
:attr:`~django.db.models.Field.default` is a valid value.
|
||||||
|
|
||||||
CSRF
|
|
||||||
^^^^
|
|
||||||
|
|
||||||
* The request header's name used for CSRF authentication can be customized
|
|
||||||
with :setting:`CSRF_HEADER_NAME`.
|
|
||||||
|
|
||||||
* The CSRF referer header is now validated against the
|
|
||||||
:setting:`CSRF_COOKIE_DOMAIN` setting if set. See :ref:`how-csrf-works` for
|
|
||||||
details.
|
|
||||||
|
|
||||||
* The new :setting:`CSRF_TRUSTED_ORIGINS` setting provides a way to allow
|
|
||||||
cross-origin unsafe requests (e.g. ``POST``) over HTTPS.
|
|
||||||
|
|
||||||
Signals
|
|
||||||
^^^^^^^
|
|
||||||
|
|
||||||
* ...
|
|
||||||
|
|
||||||
Templates
|
|
||||||
^^^^^^^^^
|
|
||||||
|
|
||||||
* Template tags created with the :meth:`~django.template.Library.simple_tag`
|
|
||||||
helper can now store results in a template variable by using the ``as``
|
|
||||||
argument.
|
|
||||||
|
|
||||||
* Added a :meth:`Context.setdefault() <django.template.Context.setdefault>`
|
|
||||||
method.
|
|
||||||
|
|
||||||
* A warning will now be logged for missing context variables. These messages
|
|
||||||
will be logged to the :ref:`django.template <django-template-logger>` logger.
|
|
||||||
|
|
||||||
* The :ttag:`firstof` template tag supports storing the output in a variable
|
|
||||||
using 'as'.
|
|
||||||
|
|
||||||
* :meth:`Context.update() <django.template.Context.update>` can now be used as
|
|
||||||
a context manager.
|
|
||||||
|
|
||||||
* Django template loaders can now extend templates recursively.
|
|
||||||
|
|
||||||
* The debug page template postmortem now include output from each engine that
|
|
||||||
is installed.
|
|
||||||
|
|
||||||
* :ref:`Debug page integration <template-debug-integration>` for custom
|
|
||||||
template engines was added.
|
|
||||||
|
|
||||||
* The :class:`~django.template.backends.django.DjangoTemplates` backend gained
|
|
||||||
the ability to register libraries and builtins explicitly through the
|
|
||||||
template :setting:`OPTIONS <TEMPLATES-OPTIONS>`.
|
|
||||||
|
|
||||||
* The ``timesince`` and ``timeuntil`` filters were improved to deal with leap
|
|
||||||
years when given large time spans.
|
|
||||||
|
|
||||||
* The ``include`` tag now caches parsed templates objects during template
|
|
||||||
rendering, speeding up reuse in places such as for loops.
|
|
||||||
|
|
||||||
Requests and Responses
|
Requests and Responses
|
||||||
^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
@ -638,6 +605,48 @@ Requests and Responses
|
||||||
the empty referer check already implemented, some Web bots set the referer to
|
the empty referer check already implemented, some Web bots set the referer to
|
||||||
the requested URL.
|
the requested URL.
|
||||||
|
|
||||||
|
Signals
|
||||||
|
^^^^^^^
|
||||||
|
|
||||||
|
* ...
|
||||||
|
|
||||||
|
Templates
|
||||||
|
^^^^^^^^^
|
||||||
|
|
||||||
|
* Template tags created with the :meth:`~django.template.Library.simple_tag`
|
||||||
|
helper can now store results in a template variable by using the ``as``
|
||||||
|
argument.
|
||||||
|
|
||||||
|
* Added a :meth:`Context.setdefault() <django.template.Context.setdefault>`
|
||||||
|
method.
|
||||||
|
|
||||||
|
* A warning will now be logged for missing context variables. These messages
|
||||||
|
will be logged to the :ref:`django.template <django-template-logger>` logger.
|
||||||
|
|
||||||
|
* The :ttag:`firstof` template tag supports storing the output in a variable
|
||||||
|
using 'as'.
|
||||||
|
|
||||||
|
* :meth:`Context.update() <django.template.Context.update>` can now be used as
|
||||||
|
a context manager.
|
||||||
|
|
||||||
|
* Django template loaders can now extend templates recursively.
|
||||||
|
|
||||||
|
* The debug page template postmortem now include output from each engine that
|
||||||
|
is installed.
|
||||||
|
|
||||||
|
* :ref:`Debug page integration <template-debug-integration>` for custom
|
||||||
|
template engines was added.
|
||||||
|
|
||||||
|
* The :class:`~django.template.backends.django.DjangoTemplates` backend gained
|
||||||
|
the ability to register libraries and builtins explicitly through the
|
||||||
|
template :setting:`OPTIONS <TEMPLATES-OPTIONS>`.
|
||||||
|
|
||||||
|
* The ``timesince`` and ``timeuntil`` filters were improved to deal with leap
|
||||||
|
years when given large time spans.
|
||||||
|
|
||||||
|
* The ``include`` tag now caches parsed templates objects during template
|
||||||
|
rendering, speeding up reuse in places such as for loops.
|
||||||
|
|
||||||
Tests
|
Tests
|
||||||
^^^^^
|
^^^^^
|
||||||
|
|
||||||
|
@ -671,23 +680,16 @@ Validators
|
||||||
* Added :func:`~django.core.validators.validate_unicode_slug` to validate slugs
|
* Added :func:`~django.core.validators.validate_unicode_slug` to validate slugs
|
||||||
that may contain Unicode characters.
|
that may contain Unicode characters.
|
||||||
|
|
||||||
Database backends
|
|
||||||
^^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
* The PostgreSQL backend (``django.db.backends.postgresql_psycopg2``) is also
|
|
||||||
available as ``django.db.backends.postgresql``. The old name will continue to
|
|
||||||
be available for backwards compatibility.
|
|
||||||
|
|
||||||
Backwards incompatible changes in 1.9
|
Backwards incompatible changes in 1.9
|
||||||
=====================================
|
=====================================
|
||||||
|
|
||||||
.. warning::
|
.. warning::
|
||||||
|
|
||||||
In addition to the changes outlined in this section, be sure to review the
|
In addition to the changes outlined in this section, be sure to review the
|
||||||
:doc:`deprecation timeline </internals/deprecation>` for any features that
|
:ref:`removed-features-1.9` for the features that have reached the end of
|
||||||
have been removed. If you haven't updated your code within the
|
their deprecation cycle and therefore been removed. If you haven't updated
|
||||||
deprecation timeline for a given feature, its removal may appear as a
|
your code within the deprecation timeline for a given feature, its removal
|
||||||
backwards incompatible change.
|
may appear as a backwards incompatible change.
|
||||||
|
|
||||||
Database backend API
|
Database backend API
|
||||||
~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~
|
||||||
|
@ -753,17 +755,18 @@ setuptools is not installed.
|
||||||
Related set direct assignment
|
Related set direct assignment
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
:ref:`Direct assignment <direct-assignment>`) used to perform a ``clear()``
|
:ref:`Direct assignment <direct-assignment>` of related objects in the ORM used
|
||||||
followed by a call to ``add()``. This caused needlessly large data changes
|
to perform a ``clear()`` followed by a call to ``add()``. This caused
|
||||||
and prevented using the :data:`~django.db.models.signals.m2m_changed` signal
|
needlessly large data changes and prevented using the
|
||||||
to track individual changes in many-to-many relations.
|
:data:`~django.db.models.signals.m2m_changed` signal to track individual
|
||||||
|
changes in many-to-many relations.
|
||||||
|
|
||||||
Direct assignment now relies on the the new
|
Direct assignment now relies on the the new
|
||||||
:meth:`django.db.models.fields.related.RelatedManager.set()` method on
|
:meth:`~django.db.models.fields.related.RelatedManager.set` method on related
|
||||||
related managers which by default only processes changes between the
|
managers which by default only processes changes between the existing related
|
||||||
existing related set and the one that's newly assigned. The previous behavior
|
set and the one that's newly assigned. The previous behavior can be restored by
|
||||||
can be restored by replacing direct assignment by a call to ``set()`` with
|
replacing direct assignment by a call to ``set()`` with the keyword argument
|
||||||
the keyword argument ``clear=True``.
|
``clear=True``.
|
||||||
|
|
||||||
``ModelForm``, and therefore ``ModelAdmin``, internally rely on direct
|
``ModelForm``, and therefore ``ModelAdmin``, internally rely on direct
|
||||||
assignment for many-to-many relations and as a consequence now use the new
|
assignment for many-to-many relations and as a consequence now use the new
|
||||||
|
@ -883,8 +886,8 @@ queries, you should turn them into naive datetimes in UTC::
|
||||||
from django.utils import timezone
|
from django.utils import timezone
|
||||||
param = timezone.make_naive(param, timezone.utc)
|
param = timezone.make_naive(param, timezone.utc)
|
||||||
|
|
||||||
If you fail to do so, Django 1.9 and 2.0 will perform the conversion like
|
If you fail to do so, the conversion will be performed as in earlier versions
|
||||||
earlier versions but emit a deprecation warning. Django 2.0 won't perform any
|
(with a deprecation warning) up until Django 1.11. Django 2.0 won't perform any
|
||||||
conversion, which may result in data corruption.
|
conversion, which may result in data corruption.
|
||||||
|
|
||||||
If you're reading :class:`~datetime.datetime` values from the results, they
|
If you're reading :class:`~datetime.datetime` values from the results, they
|
||||||
|
@ -1021,7 +1024,8 @@ Miscellaneous
|
||||||
``vendor/jquery`` subdirectory.
|
``vendor/jquery`` subdirectory.
|
||||||
|
|
||||||
* The text displayed for null columns in the admin changelist ``list_display``
|
* The text displayed for null columns in the admin changelist ``list_display``
|
||||||
cells has changed from ``(None)`` (or its translated equivalent) to ``-``.
|
cells has changed from ``(None)`` (or its translated equivalent) to ``-`` (a
|
||||||
|
dash).
|
||||||
|
|
||||||
* ``django.http.responses.REASON_PHRASES`` and
|
* ``django.http.responses.REASON_PHRASES`` and
|
||||||
``django.core.handlers.wsgi.STATUS_CODE_TEXT`` have been removed. Use
|
``django.core.handlers.wsgi.STATUS_CODE_TEXT`` have been removed. Use
|
||||||
|
@ -1297,7 +1301,7 @@ Miscellaneous
|
||||||
deprecated. Use the new ``enclosures`` argument which accepts a list of
|
deprecated. Use the new ``enclosures`` argument which accepts a list of
|
||||||
``Enclosure`` objects instead of a single one.
|
``Enclosure`` objects instead of a single one.
|
||||||
|
|
||||||
.. removed-features-1.9:
|
.. _removed-features-1.9:
|
||||||
|
|
||||||
Features removed in 1.9
|
Features removed in 1.9
|
||||||
=======================
|
=======================
|
||||||
|
|
Loading…
Reference in New Issue