test0908
/
django
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Edited Django 1.4 release notes: 

* Remove the "UNDER DEVELOPMENT" parts.
* Added an overview, explicitly mentioning time zone support.
* Spell/grammar check.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@17798 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Jacob Kaplan-Moss 2012-03-23 16:51:01 +00:00
parent f356a2e52f
commit a033d4992c
1 changed files with 190 additions and 141 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

331
docs/releases/1.4.txt
View File

@ -1,20 +1,64 @@
============================================ ========================
Django 1.4 release notes - UNDER DEVELOPMENT Django 1.4 release notes
============================================ ========================
This page documents release notes for the as-yet-unreleased Django *March 23, 2012*
1.4. As such, it's tentative and subject to change. It provides
up-to-date information for those who are following trunk.
Django 1.4 includes various `new features`_ and some minor `backwards Welcome to Django 1.4!
incompatible changes`_. We've also dropped some features, which are detailed
in :doc:`our deprecation plan </internals/deprecation>`, and we've These release notes cover the `new features`_, as well
`begun the deprecation process for some features`_. as some `backwards incompatible changes`_ you'll want to be aware of
when upgrading from Django 1.3 or older versions. We've also dropped some
features, which are detailed in :doc:`our deprecation plan
</internals/deprecation>`, and we've `begun the deprecation process for some
features`_.
.. _`new features`: `What's new in Django 1.4`_ .. _`new features`: `What's new in Django 1.4`_
.. _`backwards incompatible changes`: `Backwards incompatible changes in 1.4`_ .. _`backwards incompatible changes`: `Backwards incompatible changes in 1.4`_
.. _`begun the deprecation process for some features`: `Features deprecated in 1.4`_ .. _`begun the deprecation process for some features`: `Features deprecated in 1.4`_
Overview
========
The biggest new feature in Django 1.4 is `support for time zones`_ when
handling date/times. When enabled, this Django will store date/times in UTC,
use timezone-aware objects internally, and translate them to users' local
timezones for display.
If you're upgrading an existing project to Django 1.4, switching to the time-
zone aware mode may take some care: the new mode disallows some rather sloppy
behavior that used to be accepted. We encourage anyone who's upgrading to check
out the :ref:`timezone migration guide <time-zones-migration-guide>` and the
:ref:`timezone FAQ <time-zones-faq>` for useful pointers.
Other notable new features in Django 1.4 include:
* A number of ORM improvements, including `SELECT FOR UPDATE support`_,
the ability to `bulk insert <Model.objects.bulk_create in the ORM>`_
large datasets for improved performance, and
`QuerySet.prefetch_related`_, a method to batch-load related objects
in areas where :meth:`~django.db.models.QuerySet.select_related` does't
work.
* Some nice security additions, including `improved password hashing`_
(featuring PBKDF2_ and bcrypt_ support), new `tools for cryptographic
signing`_, several `CSRF improvements`_, and `simple clickjacking
protection`_.
* An `updated default project layout and manage.py`_ that removes the "magic"
from prior versions. And for those who don't like the new layout, you can
use `custom project and app templates`_ instead!
* `Support for in-browser testing frameworks`_ (like Selenium_).
* ... and a whole lot more; `see below <what's new in django 1.4>`_!
Wherever possible we try to introduce new features in a backwards-compatible
manner per :doc:`our API stability policy </misc/api-stability>` policy.
However, as with previous releases, Django 1.4 ships with some minor
`backwards incompatible changes`_; people upgrading from previous versions
of Django should read that list carefully.
Python compatibility Python compatibility
==================== ====================
@ -36,6 +80,33 @@ timeline for deprecating Python 2.x and moving to Python 3.x.
What's new in Django 1.4 What's new in Django 1.4
======================== ========================
Support for time zones
~~~~~~~~~~~~~~~~~~~~~~
In previous versions, Django used "naive" date/times (that is, date/times
without an associated time zone), leaving it up to each developer to interpret
what a given date/time "really means". This can cause all sorts of subtle
timezone-related bugs.
In Django 1.4, you can now switch Django into a more correct, time-zone aware
mode. In this mode, Django stores date and time information in UTC in the
database, uses time-zone-aware datetime objects internally and translates them
to the end user's time zone in templates and forms. Reasons for using this
feature include:
- Customizing date and time display for users around the world.
- Storing datetimes in UTC for database portability and interoperability.
(This argument doesn't apply to PostgreSQL, because it already stores
timestamps with time zone information in Django 1.3.)
- Avoiding data corruption problems around DST transitions.
Time zone support is enabled by default in new projects created with
:djadmin:`startproject`. If you want to use this feature in an existing
project, read the :ref:`migration guide <time-zones-migration-guide>`. If you
encounter problems, there's a helpful :ref:`FAQ <time-zones-faq>`.
Support for in-browser testing frameworks Support for in-browser testing frameworks
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -48,6 +119,110 @@ concrete examples.
.. _Selenium: http://seleniumhq.org/ .. _Selenium: http://seleniumhq.org/
Updated default project layout and ``manage.py``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django 1.4 ships with an updated default project layout and ``manage.py`` file
for the :djadmin:`startproject` management command. These fix some issues with
the previous ``manage.py`` handling of Python import paths that caused double
imports, trouble moving from development to deployment, and other
difficult-to-debug path issues.
The previous ``manage.py`` called functions that are now deprecated, and thus
projects upgrading to Django 1.4 should update their ``manage.py``. (The
old-style ``manage.py`` will continue to work as before until Django 1.6. In
1.5 it will raise ``DeprecationWarning``).
The new recommended ``manage.py`` file should look like this::
#!/usr/bin/env python
import os, sys
if __name__ == "__main__":
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name }}.settings")
from django.core.management import execute_from_command_line
execute_from_command_line(sys.argv)
``{{ project_name }}`` should be replaced with the Python package name of the
actual project.
If settings, URLconfs and apps within the project are imported or referenced
using the project name prefix (e.g. ``myproject.settings``, ``ROOT_URLCONF =
"myproject.urls"``, etc), the new ``manage.py`` will need to be moved one
directory up, so it is outside the project package rather than adjacent to
``settings.py`` and ``urls.py``.
For instance, with the following layout::
manage.py
mysite/
__init__.py
settings.py
urls.py
myapp/
__init__.py
models.py
You could import ``mysite.settings``, ``mysite.urls``, and ``mysite.myapp``,
but not ``settings``, ``urls``, or ``myapp`` as top-level modules.
Anything imported as a top-level module can be placed adjacent to the new
``manage.py``. For instance, to decouple "myapp" from the project module and
import it as just ``myapp``, place it outside the ``mysite/`` directory::
manage.py
myapp/
__init__.py
models.py
mysite/
__init__.py
settings.py
urls.py
If the same code is imported inconsistently (some places with the project
prefix, some places without it), the imports will need to be cleaned up when
switching to the new ``manage.py``.
Custom project and app templates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The :djadmin:`startapp` and :djadmin:`startproject` management commands
now have a ``--template`` option for specifying a path or URL to a custom app
or project template.
For example, Django will use the ``/path/to/my_project_template`` directory
when you run the following command::
django-admin.py startproject --template=/path/to/my_project_template myproject
You can also now provide a destination directory as the second
argument to both :djadmin:`startapp` and :djadmin:`startproject`::
django-admin.py startapp myapp /path/to/new/app
django-admin.py startproject myproject /path/to/new/project
For more information, see the :djadmin:`startapp` and :djadmin:`startproject`
documentation.
Improved WSGI support
~~~~~~~~~~~~~~~~~~~~~
The :djadmin:`startproject` management command now adds a :file:`wsgi.py`
module to the initial project layout, containing a simple WSGI application that
can be used for :doc:`deploying with WSGI app
servers</howto/deployment/wsgi/index>`.
The :djadmin:`built-in development server<runserver>` now supports using an
externally-defined WSGI callable, which makes it possible to run runserver
with the same WSGI configuration that is used for deployment. The new
:setting:`WSGI_APPLICATION` setting lets you configure which WSGI callable
:djadmin:`runserver` uses.
(The :djadmin:`runfcgi` management command also internally wraps the WSGI
callable configured via :setting:`WSGI_APPLICATION`.)
``SELECT FOR UPDATE`` support ``SELECT FOR UPDATE`` support
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -184,7 +359,7 @@ more information.
New form wizard New form wizard
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
The previous ``FormWizard`` from the formtools contrib app has been The previous ``FormWizard`` from :mod:`django.contrib.formtools` has been
replaced with a new implementation based on the class-based views replaced with a new implementation based on the class-based views
introduced in Django 1.3. It features a pluggable storage API and doesn't introduced in Django 1.3. It features a pluggable storage API and doesn't
require the wizard to pass around hidden fields for every previous step. require the wizard to pass around hidden fields for every previous step.
@ -350,137 +525,11 @@ filter<custom-error-reports>`. For more information see the docs on
Extended IPv6 support Extended IPv6 support
~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
The previously added support for IPv6 addresses when using the runserver Django 1.4 can now better handle IPv6 addresses with the new
management command in Django 1.3 has been extended with :class:`~django.db.models.fields.GenericIPAddressField` model field,
a :class:`~django.db.models.fields.GenericIPAddressField` model field, :class:`~django.forms.fields.GenericIPAddressField` form field and
a :class:`~django.forms.fields.GenericIPAddressField` form field and
the validators :data:`~django.core.validators.validate_ipv46_address` and the validators :data:`~django.core.validators.validate_ipv46_address` and
:data:`~django.core.validators.validate_ipv6_address` :data:`~django.core.validators.validate_ipv6_address`.
Updated default project layout and ``manage.py``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django 1.4 ships with an updated default project layout and ``manage.py`` file
for the :djadmin:`startproject` management command. These fix some issues with
the previous ``manage.py`` handling of Python import paths that caused double
imports, trouble moving from development to deployment, and other
difficult-to-debug path issues.
The previous ``manage.py`` called functions that are now deprecated, and thus
projects upgrading to Django 1.4 should update their ``manage.py``. (The
old-style ``manage.py`` will continue to work as before until Django 1.6. In
1.5 it will raise ``DeprecationWarning``).
The new recommended ``manage.py`` file should look like this::
#!/usr/bin/env python
import os, sys
if __name__ == "__main__":
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name }}.settings")
from django.core.management import execute_from_command_line
execute_from_command_line(sys.argv)
``{{ project_name }}`` should be replaced with the Python package name of the
actual project.
If settings, URLconfs and apps within the project are imported or referenced
using the project name prefix (e.g. ``myproject.settings``, ``ROOT_URLCONF =
"myproject.urls"``, etc), the new ``manage.py`` will need to be moved one
directory up, so it is outside the project package rather than adjacent to
``settings.py`` and ``urls.py``.
For instance, with the following layout::
manage.py
mysite/
__init__.py
settings.py
urls.py
myapp/
__init__.py
models.py
You could import ``mysite.settings``, ``mysite.urls``, and ``mysite.myapp``,
but not ``settings``, ``urls``, or ``myapp`` as top-level modules.
Anything imported as a top-level module can be placed adjacent to the new
``manage.py``. For instance, to decouple "myapp" from the project module and
import it as just ``myapp``, place it outside the ``mysite/`` directory::
manage.py
myapp/
__init__.py
models.py
mysite/
__init__.py
settings.py
urls.py
If the same code is imported inconsistently (some places with the project
prefix, some places without it), the imports will need to be cleaned up when
switching to the new ``manage.py``.
Improved WSGI support
~~~~~~~~~~~~~~~~~~~~~
The :djadmin:`startproject` management command now adds a :file:`wsgi.py`
module to the initial project layout, containing a simple WSGI application that
can be used for :doc:`deploying with WSGI app
servers</howto/deployment/wsgi/index>`.
The :djadmin:`built-in development server<runserver>` now supports using an
externally-defined WSGI callable, which makes it possible to run runserver
with the same WSGI configuration that is used for deployment. The new
:setting:`WSGI_APPLICATION` setting lets you configure which WSGI callable
:djadmin:`runserver` uses.
(The :djadmin:`runfcgi` management command also internally wraps the WSGI
callable configured via :setting:`WSGI_APPLICATION`.)
Custom project and app templates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The :djadmin:`startapp` and :djadmin:`startproject` management commands
now have a ``--template`` option for specifying a path or URL to a custom app
or project template.
For example, Django will use the ``/path/to/my_project_template`` directory
when you run the following command::
django-admin.py startproject --template=/path/to/my_project_template myproject
You can also now provide a destination directory as the second
argument to both :djadmin:`startapp` and :djadmin:`startproject`::
django-admin.py startapp myapp /path/to/new/app
django-admin.py startproject myproject /path/to/new/project
For more information, see the :djadmin:`startapp` and :djadmin:`startproject`
documentation.
Support for time zones
~~~~~~~~~~~~~~~~~~~~~~
Django 1.4 adds :ref:`support for time zones <time-zones>`. When it's enabled,
Django stores date and time information in UTC in the database, uses
time-zone-aware datetime objects internally and translates them to the end user's
time zone in templates and forms.
Reasons for using this feature include:
- Customizing date and time display for users around the world.
- Storing datetimes in UTC for database portability and interoperability.
(This argument doesn't apply to PostgreSQL, because it already stores
timestamps with time zone information in Django 1.3.)
- Avoiding data corruption problems around DST transitions.
Time zone support is enabled by default in new projects created with
:djadmin:`startproject`. If you want to use this feature in an existing
project, read the :ref:`migration guide <time-zones-migration-guide>`. If you
encounter problems, there's a helpful :ref:`FAQ <time-zones-faq>`.
HTML comparisons in tests HTML comparisons in tests
~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~