mirror of
https://github.com/django/django.git
synced 2024-11-29 14:46:18 +01:00
265 lines
6.7 KiB
Plaintext
265 lines
6.7 KiB
Plaintext
============================================
|
|
Django 1.8 release notes - UNDER DEVELOPMENT
|
|
============================================
|
|
|
|
Welcome to Django 1.8!
|
|
|
|
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
|
|
1.6 or older versions. We've also dropped some features, which are detailed in
|
|
:ref:`our deprecation plan <deprecation-removed-in-1.8>`, and we've `begun the
|
|
deprecation process for some features`_.
|
|
|
|
.. _`new features`: `What's new in Django 1.8`_
|
|
.. _`backwards incompatible changes`: `Backwards incompatible changes in 1.8`_
|
|
.. _`begun the deprecation process for some features`: `Features deprecated in 1.8`_
|
|
|
|
Python compatibility
|
|
====================
|
|
|
|
Like Django 1.7, Django 1.8 requires Python 2.7 or above, though we
|
|
**highly recommend** the latest minor release.
|
|
|
|
What's new in Django 1.8
|
|
========================
|
|
|
|
...
|
|
|
|
Minor features
|
|
~~~~~~~~~~~~~~
|
|
|
|
:mod:`django.contrib.admin`
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* ...
|
|
|
|
:mod:`django.contrib.auth`
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* ...
|
|
|
|
:mod:`django.contrib.formtools`
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* ...
|
|
|
|
:mod:`django.contrib.gis`
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* ...
|
|
|
|
:mod:`django.contrib.messages`
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* ...
|
|
|
|
:mod:`django.contrib.redirects`
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* ...
|
|
|
|
:mod:`django.contrib.sessions`
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* ...
|
|
|
|
:mod:`django.contrib.sitemaps`
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* ...
|
|
|
|
:mod:`django.contrib.sites`
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* ...
|
|
|
|
:mod:`django.contrib.staticfiles`
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* ...
|
|
|
|
:mod:`django.contrib.syndication`
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* ...
|
|
|
|
Cache
|
|
^^^^^
|
|
|
|
* ...
|
|
|
|
Email
|
|
^^^^^
|
|
|
|
* :ref:`Email backends <topic-email-backends>` now support the context manager
|
|
protocol for opening and closing connections.
|
|
|
|
File Storage
|
|
^^^^^^^^^^^^
|
|
|
|
* ...
|
|
|
|
File Uploads
|
|
^^^^^^^^^^^^
|
|
|
|
* ...
|
|
|
|
Forms
|
|
^^^^^
|
|
|
|
* Form widgets now render attributes with a value of ``True`` or ``False``
|
|
as HTML5 boolean attributes.
|
|
|
|
* The new :meth:`~django.forms.Form.has_error()` method allows checking
|
|
if a specific error has happened.
|
|
|
|
* If :attr:`~django.forms.Form.required_css_class` is defined on a form, then
|
|
the ``<label>`` tags for required fields will have this class present in its
|
|
attributes.
|
|
|
|
Internationalization
|
|
^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* ...
|
|
|
|
Management Commands
|
|
^^^^^^^^^^^^^^^^^^^
|
|
|
|
* :djadmin:`dumpdata` now has the option :djadminopt:`--output` which allows
|
|
specifying the file to which the serialized data is written.
|
|
|
|
Models
|
|
^^^^^^
|
|
|
|
* ...
|
|
|
|
Signals
|
|
^^^^^^^
|
|
|
|
* ...
|
|
|
|
Templates
|
|
^^^^^^^^^
|
|
|
|
* ...
|
|
|
|
Requests and Responses
|
|
^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* ...
|
|
|
|
Tests
|
|
^^^^^
|
|
|
|
* ...
|
|
|
|
Validators
|
|
^^^^^^^^^^
|
|
|
|
* ...
|
|
|
|
Backwards incompatible changes in 1.8
|
|
=====================================
|
|
|
|
.. warning::
|
|
|
|
In addition to the changes outlined in this section, be sure to review the
|
|
:doc:`deprecation plan </internals/deprecation>` for any features that
|
|
have been removed. If you haven't updated your code within the
|
|
deprecation timeline for a given feature, its removal may appear as a
|
|
backwards incompatible change.
|
|
|
|
* Some operations on related objects such as
|
|
:meth:`~django.db.models.fields.related.RelatedManager.add()` or
|
|
:ref:`direct assignment<direct-assignment>` ran multiple data modifying
|
|
queries without wrapping them in transactions. To reduce the risk of data
|
|
corruption, all data modifying methods that affect multiple related objects
|
|
(i.e. ``add()``, ``remove()``, ``clear()``, and
|
|
:ref:`direct assignment<direct-assignment>`) now perform their data modifying
|
|
queries from within a transaction, provided your database supports
|
|
transactions.
|
|
|
|
This has one backwards incompatible side effect, signal handlers triggered
|
|
from these methods are now executed within the method's transaction and
|
|
any exception in a signal handler will prevent the whole operation.
|
|
|
|
Miscellaneous
|
|
~~~~~~~~~~~~~
|
|
|
|
* ``URLField.to_python`` no longer adds a trailing slash to pathless URLs.
|
|
|
|
* ``django.contrib.gis`` dropped support for GEOS 3.1 and GDAL 1.6.
|
|
|
|
.. _deprecated-features-1.8:
|
|
|
|
Features deprecated in 1.8
|
|
==========================
|
|
|
|
Loading ``cycle`` and ``firstof`` template tags from ``future`` library
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Django 1.6 introduced ``{% load cycle from future %}`` and
|
|
``{% load firstof from future %}`` syntax for forward compatibility of the
|
|
:ttag:`cycle` and :ttag:`firstof` template tags. This syntax is now deprecated
|
|
and will be removed in Django 2.0. You can simply remove the
|
|
``{% load ... from future %}`` tags.
|
|
|
|
``django.conf.urls.patterns()``
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
In the olden days of Django, it was encouraged to reference views as strings
|
|
in ``urlpatterns``::
|
|
|
|
urlpatterns = patterns('',
|
|
url('^$', 'myapp.views.myview'),
|
|
)
|
|
|
|
and Django would magically import ``myapp.views.myview`` internally and turn
|
|
the string into a real function reference. In order to reduce repetition when
|
|
referencing many views from the same module, the ``patterns()`` function takes
|
|
a required initial ``prefix`` argument which is prepended to all
|
|
views-as-strings in that set of ``urlpatterns``::
|
|
|
|
urlpatterns = patterns('myapp.views',
|
|
url('^$', 'myview'),
|
|
url('^other/$', 'otherview'),
|
|
)
|
|
|
|
In the modern era, we have updated the tutorial to instead recommend importing
|
|
your views module and referencing your view functions (or classes) directly.
|
|
This has a number of advantages, all deriving from the fact that we are using
|
|
normal Python in place of "Django String Magic": the errors when you mistype a
|
|
view name are less obscure, IDEs can help with autocompletion of view names,
|
|
etc.
|
|
|
|
So these days, the above use of the ``prefix`` arg is much more likely to be
|
|
written (and is better written) as::
|
|
|
|
from myapp import views
|
|
|
|
urlpatterns = patterns('',
|
|
url('^$', views.myview),
|
|
url('^other/$', views.otherview),
|
|
)
|
|
|
|
Thus ``patterns()`` serves little purpose and is a burden when teaching new users
|
|
(answering the newbie's question "why do I need this empty string as the first
|
|
argument to ``patterns()``?"). For these reasons, we are deprecating it.
|
|
Updating your code is as simple as ensuring that ``urlpatterns`` is a string of
|
|
:func:`django.conf.urls.url` instances. For example::
|
|
|
|
from django.conf.urls import url
|
|
from myapp import views
|
|
|
|
urlpatterns = [
|
|
url('^$', views.myview),
|
|
url('^other/$', views.otherview),
|
|
]
|
|
|
|
``prefix`` argument to :func:`~django.conf.urls.i18n.i18n_patterns`
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Related to the previous item, the ``prefix`` argument to
|
|
:func:`django.conf.urls.i18n.i18n_patterns` has been deprecated. Simply pass a
|
|
list of :func:`django.conf.urls.url` instances instead.
|