innov
/
django1
1
0
Fork 0
Code Issues Pull Requests 1 Projects Releases Wiki Activity

[1.7.x] Fixed #23692 -- Removed alpha/beta/rc release notes. 

Backport of 740934b507 from master
This commit is contained in:
Tim Graham 2014-10-20 12:28:48 -04:00
parent 6f2658aa34
commit 03a20e5abd
17 changed files with 1 additions and 6226 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

161
docs/releases/1.0-alpha-1.txt
View File

@ -1,161 +0,0 @@
================================
Django 1.0 alpha release notes
================================
Welcome to Django 1.0 alpha!
This is the first in a series of preview/development releases leading
up to the eventual release of Django 1.0, currently scheduled to take
place in early September 2008. This release is primarily targeted at
developers who are interested in testing the Django codebase and
helping to identify and resolve bugs prior to the final 1.0 release.
As such, this release is *not* intended for production use, and any
such use is strongly discouraged.
What's new in Django 1.0 alpha
==============================
Django's development trunk has been the site of nearly constant
activity over the past year, with several major new features landing
since the 0.96 release. Some of the highlights include:
Refactored admin application (newforms-admin)
The Django administrative interface (``django.contrib.admin``) has
been completely refactored; admin definitions are now completely
decoupled from model definitions (no more ``class Admin``
declaration in models!), rewritten to use Django's new
form-handling library (introduced in the 0.96 release as
``django.newforms``, and now available as simply ``django.forms``)
and redesigned with extensibility and customization in mind. Full
documentation for the admin application is available online in the
official Django documentation:
* :doc:`admin reference </ref/contrib/admin/index>`
Improved Unicode handling
Django's internals have been refactored to use Unicode throughout;
this drastically simplifies the task of dealing with
non-Western-European content and data in Django. Additionally,
utility functions have been provided to ease interoperability with
third-party libraries and systems which may or may not handle
Unicode gracefully. Details are available in Django's
Unicode-handling documentation:
* :doc:`unicode reference </ref/unicode>`
An improved Django ORM
Django's object-relational mapper -- the component which provides
the mapping between Django model classes and your database, and
which mediates your database queries -- has been dramatically
improved by a massive refactoring. For most users of Django this
is backwards-compatible; the public-facing API for database
querying underwent a few minor changes, but most of the updates
took place in the ORM's internals. A guide to the changes,
including backwards-incompatible modifications and mentions of new
features opened up by this refactoring, is available on the Django
wiki:
* https://code.djangoproject.com/wiki/QuerysetRefactorBranch
Automatic escaping of template variables
To provide improved security against cross-site scripting (XSS)
vulnerabilities, Django's template system now automatically
escapes the output of variables. This behavior is configurable,
and allows both variables and larger template constructs to be
marked as safe (requiring no escaping) or unsafe (requiring
escaping). A full guide to this feature is in the documentation
for the :ttag:`autoescape` tag.
There are many more new features, many bugfixes and many enhancements
to existing features from previous releases. The ``newforms`` library,
for example, has undergone massive improvements including several
useful add-ons in ``django.contrib`` which complement and build on
Django's form-handling capabilities, and Django's file-uploading
handlers have been refactored to allow finer-grained control over the
uploading process as well as streaming uploads of large files.
Along with these improvements and additions, we've made a number of
backwards-incompatible changes to the framework, as features have been
fleshed out and APIs have been finalized for the 1.0 release. A
complete guide to these changes will be available as part of the final
Django 1.0 release, and a comprehensive list of backwards-incompatible
changes is also available on the Django wiki for those who want to
begin developing and testing their upgrade process:
* https://code.djangoproject.com/wiki/BackwardsIncompatibleChanges
The Django 1.0 roadmap
======================
One of the primary goals of this alpha release is to focus attention
on the remaining features to be implemented for Django 1.0, and on the
bugs that need to be resolved before the final release. Following
this release, we'll be conducting a series of sprints building up to a
series of beta releases and a release-candidate stage, followed soon
after by Django 1.0. The timeline is projected to be:
* August 1, 2008: Sprint (based in Washington, DC, and online).
* August 5, 2008: Django 1.0 beta 1 release. This will also constitute
the feature freeze for 1.0. Any feature to be included in 1.0 must
be completed and in trunk by this time.
* August 8, 2008: Sprint (based in Lawrence, KS, and online).
* August 12, 2008: Django 1.0 beta 2 release.
* August 15, 2008: Sprint (based in Austin, TX, and online).
* August 19, 2008: Django 1.0 release candidate 1.
* August 22, 2008: Sprint (based in Portland, OR, and online).
* August 26, 2008: Django 1.0 release candidate 2.
* September 2, 2008: Django 1.0 final release. The official Django 1.0
release party will take place during the first-ever DjangoCon, to be
held in Mountain View, CA, September 6-7.
Of course, like any estimated timeline, this is subject to change as
requirements dictate. The latest information will always be available
on the Django project wiki:
* https://code.djangoproject.com/wiki/VersionOneRoadmap
What you can do to help
=======================
In order to provide a high-quality 1.0 release, we need your
help. Although this alpha release is, again, *not* intended for
production use, you can help the Django team by trying out the alpha
codebase in a safe test environment and reporting any bugs or issues
you encounter. The Django ticket tracker is the central place to
search for open issues:
* https://code.djangoproject.com/timeline
Please open new tickets if no existing ticket corresponds to a problem
you're running into.
Additionally, discussion of Django development, including progress
toward the 1.0 release, takes place daily on the django-developers
mailing list:
* http://groups.google.com/group/django-developers
...and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If
you're interested in helping out with Django's development, feel free
to join the discussions there.
Django's online documentation also includes pointers on how to
contribute to Django:
* :doc:`contributing to Django </internals/contributing/index>`
Contributions on any level -- developing code, writing
documentation or simply triaging tickets and helping to test proposed
bugfixes -- are always welcome and appreciated.

135
docs/releases/1.0-alpha-2.txt
View File

@ -1,135 +0,0 @@
================================
Django 1.0 alpha 2 release notes
================================
Welcome to Django 1.0 alpha 2!
This is the second in a series of preview/development releases leading
up to the eventual release of Django 1.0, currently scheduled to take
place in early September 2008. This releases is primarily targeted at
developers who are interested in testing the Django codebase and
helping to identify and resolve bugs prior to the final 1.0 release.
As such, this release is *not* intended for production use, and any
such use is strongly discouraged.
What's new in Django 1.0 alpha 2
================================
Django's development trunk has been the site of nearly constant activity over
the past year, with several major new features landing since the 0.96 release.
For features which were new as of Django 1.0 alpha 1, see :doc:`the 1.0 alpha 1
release notes </releases/1.0-alpha-1>`. Since the 1.0 alpha 1 release several new
features have landed, including:
``django.contrib.gis`` (`GeoDjango`_)
A project over a year in the making, this adds world-class GIS
(`Geographic Information Systems`_) support to Django, in the form
of a ``contrib`` application. Its documentation is currently
being maintained externally, and will be merged into the main
Django documentation prior to the final 1.0 release. Huge thanks
go to Justin Bronn, Jeremy Dunck, Brett Hoerner and Travis Pinney
for their efforts in creating and completing this feature.
Pluggable file storage
Django's built-in ``FileField`` and ``ImageField`` now can take advantage of
pluggable file-storage backends, allowing extensive customization of where
and how uploaded files get stored by Django. For details, see :doc:`the
files documentation </topics/files>`; big thanks go to Marty Alchin for
putting in the hard work to get this completed.
Jython compatibility
Thanks to a lot of work from Leo Soto during a Google Summer of
Code project, Django's codebase has been refactored to remove
incompatibilities with `Jython`_, an implementation of Python
written in Java, which runs Python code on the Java Virtual
Machine. Django is now compatible with the forthcoming Jython 2.5
release.
There are many other new features and improvements in this release, including
two major performance boosts: strings marked for translation using
:doc:`Django's internationalization system </topics/i18n/index>` now consume far less
memory, and Django's internal dispatcher -- which is invoked frequently during
request/response processing and when working with Django's object-relational
mapper -- is now significantly faster.
.. _GeoDjango: http://geodjango.org/
.. _Geographic Information Systems: http://en.wikipedia.org/wiki/Geographic_information_system
.. _Jython: http://www.jython.org/
The Django 1.0 roadmap
======================
One of the primary goals of this alpha release is to focus attention
on the remaining features to be implemented for Django 1.0, and on the
bugs that need to be resolved before the final release. Following this
release, we'll be conducting a series of development sprints building
up to the beta and release-candidate stages, followed soon after by
Django 1.0. The timeline is projected to be:
* **August 14, 2008: Django 1.0 beta release.** Past this point Django
will be in a "feature freeze" for the 1.0 release; after Django 1.0
beta, the development focus will be solely on bug fixes and
stabilization.
* August 15, 2008: Sprint (based in Austin, Texas, USA, and online).
* August 17, 2008: Sprint (based in Tel Aviv, Israel, and online).
* **August 21, 2008: Django 1.0 release candidate 1.** At this point,
all strings marked for translation within Django's codebase will be
frozen, to provide contributors time to check and finalize all of
Django's bundled translation files prior to the final 1.0 release.
* August 22, 2008: Sprint (based in Portland, Oregon, USA, and online).
* **August 26, 2008: Django 1.0 release candidate 2.**
* August 30, 2008: Sprint (based in London, England, UK, and online).
* **September 2, 2008: Django 1.0 final release.** The official Django
1.0 release party will take place during the first-ever DjangoCon,
to be held in Mountain View, California, USA, September 6-7.
Of course, like any estimated timeline, this is subject to change as
requirements dictate. The latest information will always be available
on the Django project wiki:
* https://code.djangoproject.com/wiki/VersionOneRoadmap
What you can do to help
=======================
In order to provide a high-quality 1.0 release, we need your
help. Although this alpha release is, again, *not* intended for
production use, you can help the Django team by trying out the alpha
codebase in a safe test environment and reporting any bugs or issues
you encounter. The Django ticket tracker is the central place to
search for open issues:
* https://code.djangoproject.com/timeline
Please open new tickets if no existing ticket corresponds to a problem
you're running into.
Additionally, discussion of Django development, including progress
toward the 1.0 release, takes place daily on the django-developers
mailing list:
* http://groups.google.com/group/django-developers
...and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If
you're interested in helping out with Django's development, feel free
to join the discussions there.
Django's online documentation also includes pointers on how to
contribute to Django:
* :doc:`contributing to Django </internals/contributing/index>`
Contributions on any level -- developing code, writing
documentation or simply triaging tickets and helping to test proposed
bugfixes -- are always welcome and appreciated.

119
docs/releases/1.0-beta-2.txt
View File

@ -1,119 +0,0 @@
===============================
Django 1.0 beta 2 release notes
===============================
Welcome to Django 1.0 beta 2!
This is the fourth in a series of preview/development releases leading
up to the eventual release of Django 1.0, currently scheduled to take
place in early September 2008. This releases is primarily targeted at
developers who are interested in testing the Django codebase and
helping to identify and resolve bugs prior to the final 1.0 release.
As such, this release is *not* intended for production use, and any
such use is discouraged.
What's new in Django 1.0 beta 2
===============================
Django's development trunk has been the site of nearly constant
activity over the past year, with several major new features landing
since the 0.96 release. For features which were new as of Django 1.0
alpha 1, see :doc:`the 1.0 alpha 1 release notes
</releases/1.0-alpha-1>`. For features which were new as of Django 1.0
alpha 2, see :doc:`the 1.0 alpha 2 release notes
</releases/1.0-alpha-2>`. For features which were new as of Django 1.0
beta 1, see :doc:`the 1.0 beta 1 release notes </releases/1.0-beta>`.
This beta release includes two major features:
Refactored ``django.contrib.comments``
As part of a Google Summer of Code project, Thejaswi Puthraya
carried out a major rewrite and refactoring of Django's bundled
comment system, greatly increasing its flexibility and
customizability. :doc:`Full documentation
</ref/contrib/comments/index>` is available, as well as an
upgrade guide if you were using
the previous incarnation of the comments application..
Refactored documentation
Django's bundled and online documentation has also been
significantly refactored; the new documentation system uses
`Sphinx`_ to build the docs and handle such niceties as topical
indexes, reference documentation and cross-references within the
docs. You can check out the new documentation `online`_ or, if you
have Sphinx installed, build the HTML yourself from the
documentation files bundled with Django.
.. _Sphinx: http://sphinx-doc.org/
.. _online: https://docs.djangoproject.com/
Along with these new features, the Django team has also been hard at
work polishing Django's codebase for the final 1.0 release; this beta
release contains a large number of smaller improvements and bugfixes
from the ongoing push to 1.0.
Also, as part of its ongoing deprecation process, Django's old
form-handling system has been removed; this means ``django.oldforms``
no longer exists, and its various API hooks (such as automatic
manipulators) are no longer present in Django. This system has been
completely replaced by :doc:`the new form-handling system
</topics/forms/index>` in ``django.forms``.
The Django 1.0 roadmap
======================
One of the primary goals of this beta release is to focus attention on
the remaining features to be implemented for Django 1.0, and on the
bugs that need to be resolved before the final release. As of this
beta release, Django is in its final "feature freeze" for 1.0; feature
requests will be deferred to later releases, and the development
effort will be focused solely on bugfixing and stability. Django is
also now in a "string freeze"; translatable strings (labels, error
messages, etc.) in Django's codebase will not be changed prior to the
release, in order to allow our translators to produce the final 1.0
version of Django's translation files.
Following this release, we'll be conducting a final development sprint
on August 30, 2008, based in London and coordinated online; the goal
of this sprint will be to squash as many bugs as possible in
anticipation of the final 1.0 release, which is currently targeted for
**September 2, 2008**. The official Django 1.0 release party will take
place during the first-ever DjangoCon, to be held in Mountain View,
California, USA, September 6-7.
What you can do to help
=======================
In order to provide a high-quality 1.0 release, we need your
help. Although this beta release is, again, *not* intended for
production use, you can help the Django team by trying out the beta
codebase in a safe test environment and reporting any bugs or issues
you encounter. The Django ticket tracker is the central place to
search for open issues:
* https://code.djangoproject.com/timeline
Please open new tickets if no existing ticket corresponds to a problem
you're running into.
Additionally, discussion of Django development, including progress
toward the 1.0 release, takes place daily on the django-developers
mailing list:
* http://groups.google.com/group/django-developers
...and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If
you're interested in helping out with Django's development, feel free
to join the discussions there.
Django's online documentation also includes pointers on how to
contribute to Django:
* :doc:`contributing to Django </internals/contributing/index>`
Contributions on any level -- developing code, writing
documentation or simply triaging tickets and helping to test proposed
bugfixes -- are always welcome and appreciated.

153
docs/releases/1.0-beta.txt
View File

@ -1,153 +0,0 @@
===============================
Django 1.0 beta 1 release notes
===============================
Welcome to Django 1.0 beta 1!
This is the third in a series of preview/development releases leading
up to the eventual release of Django 1.0, currently scheduled to take
place in early September 2008. This releases is primarily targeted at
developers who are interested in testing the Django codebase and
helping to identify and resolve bugs prior to the final 1.0 release.
As such, this release is *not* intended for production use, and any
such use is discouraged.
What's new in Django 1.0 beta 1
===============================
Django's development trunk has been the site of nearly constant activity over
the past year, with several major new features landing since the 0.96 release.
For features which were new as of Django 1.0 alpha 1, see :doc:`the 1.0 alpha 1
release notes </releases/1.0-alpha-1>`. For features which were new as of Django
1.0 alpha 2, see :doc:`the 1.0 alpha 2 release notes </releases/1.0-alpha-2>`.
This beta release does not contain any major new features, but does
include several smaller updates and improvements to Django:
Generic relations in forms and admin
Classes are now included in ``django.contrib.contenttypes`` which
can be used to support generic relations in both the admin
interface and in end-user forms. See :ref:`the documentation for
generic relations <generic-relations>` for details.
Improved flexibility in the admin
Following up on the refactoring of Django's administrative
interface (``django.contrib.admin``), introduced in Django 1.0
alpha 1, two new hooks have been added to allow customized pre-
and post-save handling of model instances in the admin. Full
details are in :doc:`the admin documentation </ref/contrib/admin/index>`.
``INSERT``/``UPDATE`` distinction
Although Django's default behavior of having a model's ``save()``
method automatically determine whether to perform an ``INSERT`` or
an ``UPDATE`` at the SQL level is suitable for the majority of
cases, there are occasional situations where forcing one or the
other is useful. As a result, models can now support an additional
parameter to ``save()`` which can force a specific
operation. Consult the database API documentation for details
and important notes about appropriate use of this parameter.
Split ``CacheMiddleware``
Django's ``CacheMiddleware`` has been split into three classes:
``CacheMiddleware`` itself still exists and retains all of its
previous functionality, but it is now built from two separate
middleware classes which handle the two parts of caching (inserting
into and reading from the cache) separately, offering additional
flexibility for situations where combining these functions into a
single middleware posed problems. Full details, including updated
notes on appropriate use, are in
:doc:`the caching documentation </topics/cache>`.
Removal of deprecated features
A number of features and methods which had previously been marked
as deprecated, and which were scheduled for removal prior to the
1.0 release, are no longer present in Django. These include
imports of the form library from ``django.newforms`` (now located
simply at ``django.forms``), the ``form_for_model`` and
``form_for_instance`` helper functions (which have been replaced
by ``ModelForm``) and a number of deprecated features which were
replaced by the dispatcher, file-uploading and file-storage
refactorings introduced in the Django 1.0 alpha releases. A full
list of these and all other backwards-incompatible changes is
available on `the Django wiki`_.
A number of other improvements and bugfixes have also been included:
some tricky cases involving case-sensitivity in differing MySQL
collations have been resolved, Windows packaging and installation has
been improved and the method by which Django generates unique session
identifiers has been made much more robust.
.. _the documentation for generic relations: ../contenttypes/#generic-relations
.. _the Django wiki: https://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Removedseveralmoredeprecatedfeaturesfor1.0
The Django 1.0 roadmap
======================
One of the primary goals of this beta release is to focus attention on
the remaining features to be implemented for Django 1.0, and on the
bugs that need to be resolved before the final release. Following this
release, we'll be conducting a series of development sprints building
up to the release-candidate stage, followed soon after by Django
1.0. The timeline is projected to be:
* August 15, 2008: Sprint (based in Austin, Texas, USA, and online).
* August 17, 2008: Sprint (based in Tel Aviv, Israel, and online).
* **August 21, 2008: Django 1.0 release candidate 1.** At this point,
all strings marked for translation within Django's codebase will be
frozen, to provide contributors time to check and finalize all of
Django's bundled translation files prior to the final 1.0 release.
* August 22, 2008: Sprint (based in Portland, Oregon, USA, and online).
* **August 26, 2008: Django 1.0 release candidate 2.**
* August 30, 2008: Sprint (based in London, England, UK, and online).
* **September 2, 2008: Django 1.0 final release.** The official Django
1.0 release party will take place during the first-ever DjangoCon,
to be held in Mountain View, California, USA, September 6-7.
Of course, like any estimated timeline, this is subject to change as
requirements dictate. The latest information will always be available
on the Django project wiki:
* https://code.djangoproject.com/wiki/VersionOneRoadmap
What you can do to help
=======================
In order to provide a high-quality 1.0 release, we need your
help. Although this beta release is, again, *not* intended for
production use, you can help the Django team by trying out the beta
codebase in a safe test environment and reporting any bugs or issues
you encounter. The Django ticket tracker is the central place to
search for open issues:
* https://code.djangoproject.com/timeline
Please open new tickets if no existing ticket corresponds to a problem
you're running into.
Additionally, discussion of Django development, including progress
toward the 1.0 release, takes place daily on the django-developers
mailing list:
* http://groups.google.com/group/django-developers
...and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If
you're interested in helping out with Django's development, feel free
to join the discussions there.
Django's online documentation also includes pointers on how to
contribute to Django:
* :doc:`contributing to Django </internals/contributing/index>`
Contributions on any level -- developing code, writing
documentation or simply triaging tickets and helping to test proposed
bugfixes -- are always welcome and appreciated.

165
docs/releases/1.1-alpha-1.txt
View File

@ -1,165 +0,0 @@
================================
Django 1.1 alpha 1 release notes
================================
February 23, 2009
Welcome to Django 1.1 alpha 1!
This is the first in a series of preview/development releases leading up to the
eventual release of Django 1.1, currently scheduled to take place in April 2009.
This release is primarily targeted at developers who are interested in trying
out new features and testing the Django codebase to help identify and resolve
bugs prior to the final 1.1 release.
As such, this release is *not* intended for production use, and any such use is
discouraged.
What's new in Django 1.1 alpha 1
================================
ORM improvements
----------------
Two major enhancements have been added to Django's object-relational mapper
(ORM):
Aggregate support
~~~~~~~~~~~~~~~~~
.. currentmodule:: django.db.models
It's now possible to run SQL aggregate queries (i.e. ``COUNT()``, ``MAX()``,
``MIN()``, etc.) from within Django's ORM. You can choose to either return the
results of the aggregate directly, or else annotate the objects in a
:class:`~django.db.models.query.QuerySet` with the results of the aggregate
query.
This feature is available as new
:meth:`~django.db.models.query.QuerySet.aggregate` and
:meth:`~django.db.models.query.QuerySet.annotate` methods, and is covered in
detail in :doc:`the ORM aggregation documentation </topics/db/aggregation>`.
Query expressions
~~~~~~~~~~~~~~~~~
Queries can now refer to a another field on the query and can traverse
relationships to refer to fields on related models. This is implemented in the
new :class:`F` object; for full details, including examples, consult the
:class:`F expressions documentation <django.db.models.F>`.
Performance improvements
------------------------
.. currentmodule:: django.test
Tests written using Django's :doc:`testing framework </topics/testing/index>`
now run dramatically faster (as much as 10 times faster in many cases).
This was accomplished through the introduction of transaction-based tests: when
using :class:`django.test.TestCase`, your tests will now be run in a transaction
which is rolled back when finished, instead of by flushing and re-populating the
database. This results in an immense speedup for most types of unit tests. See
the documentation for :class:`TestCase` and :class:`TransactionTestCase` for a
full description, and some important notes on database support.
Other improvements
------------------
Other new features and changes introduced since Django 1.0 include:
* The :doc:`CSRF protection middleware </ref/contrib/csrf>` has been split into
two classes -- ``CsrfViewMiddleware`` checks incoming requests, and
``CsrfResponseMiddleware`` processes outgoing responses. The combined
``CsrfMiddleware`` class (which does both) remains for
backwards-compatibility, but using the split classes is now recommended in
order to allow fine-grained control of when and where the CSRF processing
takes place.
* :func:`~django.core.urlresolvers.reverse` and code which uses it (e.g., the
``{% url %}`` template tag) now works with URLs in Django's administrative
site, provided that the admin URLs are set up via ``include(admin.site.urls)``
(sending admin requests to the ``admin.site.root`` view still works, but URLs
in the admin will not be "reversible" when configured this way).
* The ``include()`` function in Django URLconf modules can now accept sequences
of URL patterns (generated by ``patterns()``) in addition to module names.
* Instances of Django forms (see :doc:`the forms overview </topics/forms/index>`)
now have two additional methods, ``hidden_fields()`` and ``visible_fields()``,
which return the list of hidden -- i.e., ``<input type="hidden">`` -- and
visible fields on the form, respectively.
* The ``redirect_to`` generic view
now accepts an additional keyword argument
``permanent``. If ``permanent`` is ``True``, the view will emit an HTTP
permanent redirect (status code 301). If ``False``, the view will emit an HTTP
temporary redirect (status code 302).
* A new database lookup type -- ``week_day`` -- has been added for ``DateField``
and ``DateTimeField``. This type of lookup accepts a number between 1 (Sunday)
and 7 (Saturday), and returns objects where the field value matches that day
of the week. See :ref:`the full list of lookup types <field-lookups>` for
details.
* The ``{% for %}`` tag in Django's template language now accepts an optional
``{% empty %}`` clause, to be displayed when ``{% for %}`` is asked to loop
over an empty sequence. See :doc:`the list of built-in template tags
</ref/templates/builtins>` for examples of this.
The Django 1.1 roadmap
======================
Before Django 1.1 goes final, several other preview/development releases will be
made available. The current schedule consists of at least the following:
* Week of *March 20, 2009:* Django 1.1 beta 1, at which point Django 1.1 will
be in "feature freeze": no new features will be implemented for 1.1
past that point, and all new feature work will be deferred to
Django 1.2.
* Week of *April 2, 2009:* Django 1.1 release candidate. At this point all
strings marked for translation must freeze to allow translations to
be submitted in advance of the final release.
* Week of *April 13, 2009:* Django 1.1 final.
If deemed necessary, additional alpha, beta or release candidate packages will
be issued prior to the final 1.1 release.
What you can do to help
=======================
In order to provide a high-quality 1.1 release, we need your help. Although this
alpha release is, again, *not* intended for production use, you can help the
Django team by trying out the alpha codebase in a safe test environment and
reporting any bugs or issues you encounter. The Django ticket tracker is the
central place to search for open issues:
* https://code.djangoproject.com/timeline
Please open new tickets if no existing ticket corresponds to a problem you're
running into.
Additionally, discussion of Django development, including progress toward the
1.1 release, takes place daily on the django-developers mailing list:
* http://groups.google.com/group/django-developers
... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
interested in helping out with Django's development, feel free to join the
discussions there.
Django's online documentation also includes pointers on how to contribute to
Django:
* :doc:`How to contribute to Django </internals/contributing/index>`
Contributions on any level -- developing code, writing documentation or simply
triaging tickets and helping to test proposed bugfixes -- are always welcome and
appreciated.
Development sprints for Django 1.1 will also be taking place at PyCon US 2009,
on the dedicated sprint days (March 30 through April 2), and anyone who wants to
help out is welcome to join in, either in person at PyCon or virtually in the
IRC channel or on the mailing list.

208
docs/releases/1.1-beta-1.txt
View File

@ -1,208 +0,0 @@
===============================
Django 1.1 beta 1 release notes
===============================
March 23, 2009
Welcome to Django 1.1 beta 1!
This is the second in a series of preview/development releases leading up to
the eventual release of Django 1.1, currently scheduled to take place in April
2009. This release is primarily targeted at developers who are interested in
trying out new features and testing the Django codebase to help identify and
resolve bugs prior to the final 1.1 release.
As such, this release is *not* intended for production use, and any such use
is discouraged.
What's new in Django 1.1 beta 1
===============================
.. seealso::
The :doc:`1.1 alpha release notes </releases/1.1-alpha-1>`, which has a
list of everything new between Django 1.0 and Django 1.1 alpha.
Model improvements
------------------
.. currentmodule:: django.db.models
A number of features have been added to Django's model layer:
"Unmanaged" models
~~~~~~~~~~~~~~~~~~
You can now control whether or not Django creates database tables for a model
using the :attr:`~Options.managed` model option. This defaults to ``True``,
meaning that Django will create the appropriate database tables in
:djadmin:`syncdb` and remove them as part of ``reset`` command. That
is, Django *manages* the database table's lifecycle.
If you set this to ``False``, however, no database table creating or deletion
will be automatically performed for this model. This is useful if the model
represents an existing table or a database view that has been created by some
other means.
For more details, see the documentation for the :attr:`~Options.managed`
option.
Proxy models
~~~~~~~~~~~~
You can now create :ref:`proxy models <proxy-models>`: subclasses of existing
models that only add Python behavior and aren't represented by a new table.
That is, the new model is a *proxy* for some underlying model, which stores
all the real data.
All the details can be found in the :ref:`proxy models documentation
<proxy-models>`. This feature is similar on the surface to unmanaged models,
so the documentation has an explanation of :ref:`how proxy models differ from
unmanaged models <proxy-vs-unmanaged-models>`.
Deferred fields
~~~~~~~~~~~~~~~
In some complex situations, your models might contain fields which could
contain a lot of data (for example, large text fields), or require expensive
processing to convert them to Python objects. If you know you don't need those
particular fields, you can now tell Django not to retrieve them from the
database.
You'll do this with the new queryset methods
:meth:`~django.db.models.query.QuerySet.defer` and
:meth:`~django.db.models.query.QuerySet.only`.
New admin features
------------------
Since 1.1 alpha, a couple of new features have been added to Django's admin
application:
Editable fields on the change list
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can now make fields editable on the admin list views via the new
:ref:`list_editable <admin-list-editable>` admin option. These fields will show
up as form widgets on the list pages, and can be edited and saved in bulk.
Admin "actions"
~~~~~~~~~~~~~~~
You can now define :doc:`admin actions </ref/contrib/admin/actions>` that can perform
some action to a group of models in bulk. Users will be able to select objects on
the change list page and then apply these bulk actions to all selected objects.
Django ships with one pre-defined admin action to delete a group of objects in
one fell swoop.
Testing improvements
--------------------
.. currentmodule:: django.test
A couple of small but very useful improvements have been made to the
:doc:`testing framework </topics/testing/index>`:
* The test :class:`Client` now can automatically follow redirects with the
``follow`` argument to :meth:`Client.get` and :meth:`Client.post`. This
makes testing views that issue redirects simpler.
* It's now easier to get at the template context in the response returned
the test client: you'll simply access the context as
``request.context[key]``. The old way, which treats ``request.context``
as a list of contexts, one for each rendered template, is still
available if you need it.
Conditional view processing
---------------------------
Django now has much better support for :doc:`conditional view processing
</topics/conditional-view-processing>` using the standard ``ETag`` and
``Last-Modified`` HTTP headers. This means you can now easily short-circuit
view processing by testing less-expensive conditions. For many views this can
lead to a serious improvement in speed and reduction in bandwidth.
Other improvements
------------------
Finally, a grab-bag of other neat features made their way into this beta
release, including:
* The :djadmin:`dumpdata` management command now accepts individual
model names as arguments, allowing you to export the data just from
particular models.
* There's a new :tfilter:`safeseq` template filter which works just like
:tfilter:`safe` for lists, marking each item in the list as safe.
* :doc:`Cache backends </topics/cache>` now support ``incr()`` and
``decr()`` commands to increment and decrement the value of a cache key.
On cache backends that support atomic increment/decrement -- most
notably, the memcached backend -- these operations will be atomic, and
quite fast.
* Django now can :doc:`easily delegate authentication to the Web server
</howto/auth-remote-user>` via a new authentication backend that supports
the standard ``REMOTE_USER`` environment variable used for this purpose.
* There's a new :func:`django.shortcuts.redirect` function that makes it
easier to issue redirects given an object, a view name, or a URL.
* The ``postgresql_psycopg2`` backend now supports :ref:`native PostgreSQL
autocommit <postgresql-notes>`. This is an advanced, PostgreSQL-specific
feature, that can make certain read-heavy applications a good deal
faster.
The Django 1.1 roadmap
======================
Before Django 1.1 goes final, at least one other preview/development release
will be made available. The current schedule consists of at least the
following:
* Week of *April 2, 2009:* Django 1.1 release candidate. At this point all
strings marked for translation must freeze to allow translations to
be submitted in advance of the final release.
* Week of *April 13, 2009:* Django 1.1 final.
If deemed necessary, additional beta or release candidate packages will be
issued prior to the final 1.1 release.
What you can do to help
=======================
In order to provide a high-quality 1.1 release, we need your help. Although this
beta release is, again, *not* intended for production use, you can help the
Django team by trying out the beta codebase in a safe test environment and
reporting any bugs or issues you encounter. The Django ticket tracker is the
central place to search for open issues:
* https://code.djangoproject.com/timeline
Please open new tickets if no existing ticket corresponds to a problem you're
running into.
Additionally, discussion of Django development, including progress toward the
1.1 release, takes place daily on the django-developers mailing list:
* http://groups.google.com/group/django-developers
... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
interested in helping out with Django's development, feel free to join the
discussions there.
Django's online documentation also includes pointers on how to contribute to
Django:
* :doc:`How to contribute to Django </internals/contributing/index>`
Contributions on any level -- developing code, writing documentation or simply
triaging tickets and helping to test proposed bugfixes -- are always welcome and
appreciated.
Development sprints for Django 1.1 will also be taking place at PyCon US 2009,
on the dedicated sprint days (March 30 through April 2), and anyone who wants to
help out is welcome to join in, either in person at PyCon or virtually in the
IRC channel or on the mailing list.

109
docs/releases/1.1-rc-1.txt
View File

@ -1,109 +0,0 @@
=============================
Django 1.1 RC 1 release notes
=============================
July 21, 2009
Welcome to the first Django 1.1 release candidate!
This is the third -- and likely last -- in a series of
preview/development releases leading up to the eventual release of
Django 1.1, currently scheduled to take place approximately one week
after this release candidate. This release is targeted primarily at
developers who are interested in trying out new features and testing
the Django codebase to help identify and resolve any critical bugs
prior to the final 1.1 release.
As such, this release is not yet intended for production use, and any
such use is discouraged.
What's new in Django 1.1 RC 1
=============================
The Django codebase has -- with one exception -- been in feature
freeze since the first 1.1 beta release, and so this release candidate
contains only one new feature (see below); work leading up to this
release candidate has instead been focused on bugfixing, particularly
on the new features introduced prior to the 1.1 beta.
For an overview of those features, consult :doc:`the Django 1.1 beta
release notes </releases/1.1-beta-1>`.
URL namespaces
--------------
The 1.1 beta release introduced the ability to use reverse URL
resolution with Django's admin application, which exposed a set of
:ref:`named URLs <naming-url-patterns>`. Unfortunately, achieving
consistent and correct reverse resolution for admin URLs proved
extremely difficult, and so one additional feature was added to Django
to resolve this issue: URL namespaces.
In short, this feature allows the same group of URLs, from the same
application, to be included in a Django URLConf multiple times, with
varying (and potentially nested) named prefixes which will be used
when performing reverse resolution. For full details, see :ref:`the
documentation on defining URL namespaces
<topics-http-defining-url-namespaces>`.
Due to the changes needed to support this feature, the URL pattern
names used when reversing admin URLs have changed since the 1.1 beta
release; if you were developing applications which took advantage of
this new feature, you will need to update your code to reflect the new
names (for most purposes, changing ``admin_`` to ``admin:`` in names
to be reversed will suffice). For a full list of URL pattern names
used by the admin and information on how namespaces are applied to
them, consult the documentation on :ref:`reversing admin URLs
<admin-reverse-urls>`.
The Django 1.1 roadmap
======================
As of this release candidate, Django 1.1 is in both feature freeze and
"string freeze" -- all strings marked for translation in the Django
codebase will retain their current form in the final Django 1.1
release. Only critical release-blocking bugs will receive attention
between now and the final 1.1 release.
If no such bugs are discovered, Django 1.1 will be released
approximately one week after this release candidate, on or about July
28, 2009.
What you can do to help
=======================
In order to provide a high-quality 1.1 release, we need your
help. Although this release candidate is, again, *not* intended for
production use, you can help the Django team by trying out this
release candidate in a safe testing environment and reporting any bugs
or issues you encounter. The Django ticket tracker is the central
place to search for open issues:
* https://code.djangoproject.com/timeline
Please open a new ticket only if no existing ticket corresponds to a
problem you're running into.
Additionally, discussion of Django development, including progress
toward the 1.1 release, takes place daily on the django-developers
mailing list:
* http://groups.google.com/group/django-developers
... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
interested in helping out with Django's development, feel free to join the
discussions there.
Django's online documentation also includes pointers on how to contribute to
Django:
* :doc:`How to contribute to Django </internals/contributing/index>`
Contributions on any level -- developing code, writing documentation or simply
triaging tickets and helping to test proposed bugfixes -- are always welcome and
appreciated.

588
docs/releases/1.2-alpha-1.txt
View File

@ -1,588 +0,0 @@
================================
Django 1.2 alpha 1 release notes
================================
January 5, 2010
Welcome to Django 1.2 alpha 1!
This is the first in a series of preview/development releases leading up to the
eventual release of Django 1.2, currently scheduled to take place in March 2010.
This release is primarily targeted at developers who are interested in trying
out new features and testing the Django codebase to help identify and resolve
bugs prior to the final 1.2 release.
As such, this release is *not* intended for production use, and any such use is
discouraged.
Backwards-incompatible changes in 1.2
=====================================
CSRF Protection
---------------
There have been large changes to the way that CSRF protection works, detailed in
:doc:`the CSRF documentation </ref/contrib/csrf>`. The following are the major
changes that developers must be aware of:
* ``CsrfResponseMiddleware`` and ``CsrfMiddleware`` have been deprecated, and
**will be removed completely in Django 1.4**, in favor of a template tag that
should be inserted into forms.
* All contrib apps use a ``csrf_protect`` decorator to protect the view. This
requires the use of the ``csrf_token`` template tag in the template, so if you
have used custom templates for contrib views, you MUST READ THE UPGRADE
INSTRUCTIONS to fix those templates.
.. admonition:: Documentation removed
The upgrade notes have been removed in current Django docs. Please refer
to the docs for Django 1.3 or older to find these instructions.
* ``CsrfViewMiddleware`` is included in :setting:`MIDDLEWARE_CLASSES` by
default. This turns on CSRF protection by default, so that views that accept
POST requests need to be written to work with the middleware. Instructions
on how to do this are found in the CSRF docs.
* CSRF-related code has moved from ``contrib`` to ``core`` (with
backwards compatible imports in the old locations, which are
deprecated).
:ttag:`if` tag changes
----------------------
Due to new features in the :ttag:`if` template tag, it no longer accepts 'and',
'or' and 'not' as valid **variable** names. Previously that worked in some
cases even though these strings were normally treated as keywords. Now, the
keyword status is always enforced, and template code like ``{% if not %}`` or
``{% if and %}`` will throw a TemplateSyntaxError.
``LazyObject``
--------------
``LazyObject`` is an undocumented utility class used for lazily wrapping other
objects of unknown type. In Django 1.1 and earlier, it handled introspection in
a non-standard way, depending on wrapped objects implementing a public method
``get_all_members()``. Since this could easily lead to name clashes, it has been
changed to use the standard method, involving ``__members__`` and ``__dir__()``.
If you used ``LazyObject`` in your own code, and implemented the
``get_all_members()`` method for wrapped objects, you need to make the following
changes:
* If your class does not have special requirements for introspection (i.e. you
have not implemented ``__getattr__()`` or other methods that allow for
attributes not discoverable by normal mechanisms), you can simply remove the
``get_all_members()`` method. The default implementation on ``LazyObject``
will do the right thing.
* If you have more complex requirements for introspection, first rename the
``get_all_members()`` method to ``__dir__()``. This is the standard method,
from Python 2.6 onwards, for supporting introspection. If you are require
support for Python < 2.6, add the following code to the class::
__members__ = property(lambda self: self.__dir__())
``__dict__`` on Model instances
-------------------------------
Historically, the ``__dict__`` attribute of a model instance has only contained
attributes corresponding to the fields on a model.
In order to support multiple database configurations, Django 1.2 has
added a ``_state`` attribute to object instances. This attribute will
appear in ``__dict__`` for a model instance. If your code relies on
iterating over __dict__ to obtain a list of fields, you must now
filter the ``_state`` attribute of out ``__dict__``.
``get_db_prep_*()`` methods on Field
------------------------------------
Prior to v1.2, a custom field had the option of defining several
functions to support conversion of Python values into
database-compatible values. A custom field might look something like::
class CustomModelField(models.Field):
# ...
def get_db_prep_save(self, value):
# ...
def get_db_prep_value(self, value):
# ...
def get_db_prep_lookup(self, lookup_type, value):
# ...
In 1.2, these three methods have undergone a change in prototype, and
two extra methods have been introduced::
class CustomModelField(models.Field):
# ...
def get_prep_value(self, value):
# ...
def get_prep_lookup(self, lookup_type, value):
# ...
def get_db_prep_save(self, value, connection):
# ...
def get_db_prep_value(self, value, connection, prepared=False):
# ...
def get_db_prep_lookup(self, lookup_type, value, connection, prepared=False):
# ...
These changes are required to support multiple databases:
``get_db_prep_*`` can no longer make any assumptions regarding the
database for which it is preparing. The ``connection`` argument now
provides the preparation methods with the specific connection for
which the value is being prepared.
The two new methods exist to differentiate general data preparation
requirements, and requirements that are database-specific. The
``prepared`` argument is used to indicate to the database preparation
methods whether generic value preparation has been performed. If
an unprepared (i.e., ``prepared=False``) value is provided to the
``get_db_prep_*()`` calls, they should invoke the corresponding
``get_prep_*()`` calls to perform generic data preparation.
Conversion functions has been provided which will transparently
convert functions adhering to the old prototype into functions
compatible with the new prototype. However, this conversion function
will be removed in Django 1.4, so you should upgrade your Field
definitions to use the new prototype.
If your ``get_db_prep_*()`` methods made no use of the database
connection, you should be able to upgrade by renaming
``get_db_prep_value()`` to ``get_prep_value()`` and
``get_db_prep_lookup()`` to ``get_prep_lookup()`. If you require
database specific conversions, then you will need to provide an
implementation ``get_db_prep_*`` that uses the ``connection``
argument to resolve database-specific values.
Stateful template tags
----------------------
Template tags that store rendering state on the node itself may experience
problems if they are used with the new :ref:`cached
template loader<template-loaders>`.
All of the built-in Django template tags are safe to use with the cached
loader, but if you're using custom template tags that come from third
party packages, or that you wrote yourself, you should ensure that the
``Node`` implementation for each tag is thread-safe. For more
information, see
:ref:`template tag thread safety considerations<template_tag_thread_safety>`.
Test runner exit status code
----------------------------
The exit status code of the test runners (``tests/runtests.py`` and ``python
manage.py test``) no longer represents the number of failed tests, since a
failure of 256 or more tests resulted in a wrong exit status code. The exit
status code for the test runner is now 0 for success (no failing tests) and 1
for any number of test failures. If needed, the number of test failures can be
found at the end of the test runner's output.
Features deprecated in 1.2
==========================
CSRF response rewriting middleware
----------------------------------
``CsrfResponseMiddleware``, the middleware that automatically inserted CSRF
tokens into POST forms in outgoing pages, has been deprecated in favor of a
template tag method (see above), and will be removed completely in Django
1.4. ``CsrfMiddleware``, which includes the functionality of
``CsrfResponseMiddleware`` and ``CsrfViewMiddleware`` has likewise been
deprecated.
Also, the CSRF module has moved from contrib to core, and the old
imports are deprecated, as described in the upgrading notes.
.. admonition:: Documentation removed
The upgrade notes have been removed in current Django docs. Please refer
to the docs for Django 1.3 or older to find these instructions.
``SMTPConnection``
------------------
The ``SMTPConnection`` class has been deprecated in favor of a generic
Email backend API. Old code that explicitly instantiated an instance
of an SMTPConnection::
from django.core.mail import SMTPConnection
connection = SMTPConnection()
messages = get_notification_email()
connection.send_messages(messages)
should now call :meth:`~django.core.mail.get_connection()` to
instantiate a generic email connection::
from django.core.mail import get_connection
connection = get_connection()
messages = get_notification_email()
connection.send_messages(messages)
Depending on the value of the :setting:`EMAIL_BACKEND` setting, this
may not return an SMTP connection. If you explicitly require an SMTP
connection with which to send email, you can explicitly request an
SMTP connection::
from django.core.mail import get_connection
connection = get_connection('django.core.mail.backends.smtp.EmailBackend')
messages = get_notification_email()
connection.send_messages(messages)
If your call to construct an instance of ``SMTPConnection`` required
additional arguments, those arguments can be passed to the
:meth:`~django.core.mail.get_connection()` call::
connection = get_connection('django.core.mail.backends.smtp.EmailBackend', hostname='localhost', port=1234)
Specifying databases
--------------------
Prior to Django 1.1, Django used a number of settings to control access to a
single database. Django 1.2 introduces support for multiple databases, and as
a result, the way you define database settings has changed.
**Any existing Django settings file will continue to work as expected
until Django 1.4.** Old-style database settings will be automatically
translated to the new-style format.
In the old-style (pre 1.2) format, there were a number of
``DATABASE_`` settings at the top level of your settings file. For
example::
DATABASE_NAME = 'test_db'
DATABASE_ENGINE = 'postgresql_psycopg2'
DATABASE_USER = 'myusername'
DATABASE_PASSWORD = 's3krit'
These settings are now contained inside a dictionary named
:setting:`DATABASES`. Each item in the dictionary corresponds to a
single database connection, with the name ``'default'`` describing the
default database connection. The setting names have also been
shortened to reflect the fact that they are stored in a dictionary.
The sample settings given previously would now be stored using::
DATABASES = {
'default': {
'NAME': 'test_db',
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'USER': 'myusername',
'PASSWORD': 's3krit',
}
}
This affects the following settings:
========================================= ==========================
Old setting New Setting
========================================= ==========================
`DATABASE_ENGINE` :setting:`ENGINE <DATABASE-ENGINE>`
`DATABASE_HOST` :setting:`HOST`
`DATABASE_NAME` :setting:`NAME`
`DATABASE_OPTIONS` :setting:`OPTIONS`
`DATABASE_PASSWORD` :setting:`PASSWORD`
`DATABASE_PORT` :setting:`PORT`
`DATABASE_USER` :setting:`USER`
`TEST_DATABASE_CHARSET` :setting:`TEST_CHARSET`
`TEST_DATABASE_COLLATION` :setting:`TEST_COLLATION`
`TEST_DATABASE_NAME` :setting:`TEST_NAME`
========================================= ==========================
These changes are also required if you have manually created a database
connection using ``DatabaseWrapper()`` from your database backend of choice.
In addition to the change in structure, Django 1.2 removes the special
handling for the built-in database backends. All database backends
must now be specified by a fully qualified module name (i.e.,
``django.db.backends.postgresql_psycopg2``, rather than just
``postgresql_psycopg2``).
User Messages API
-----------------
The API for storing messages in the user ``Message`` model (via
``user.message_set.create``) is now deprecated and will be removed in Django
1.4 according to the standard :doc:`release process </internals/release-process>`.
To upgrade your code, you need to replace any instances of::
user.message_set.create('a message')
with the following::
from django.contrib import messages
messages.add_message(request, messages.INFO, 'a message')
Additionally, if you make use of the method, you need to replace the
following::
for message in user.get_and_delete_messages():
...
with::
from django.contrib import messages
for message in messages.get_messages(request):
...
For more information, see the full
:doc:`messages documentation </ref/contrib/messages>`. You should begin to
update your code to use the new API immediately.
Date format helper functions
----------------------------
``django.utils.translation.get_date_formats()`` and
``django.utils.translation.get_partial_date_formats()`` have been deprecated
in favor of the appropriate calls to ``django.utils.formats.get_format()``
which is locale aware when :setting:`USE_L10N` is set to ``True``, and falls
back to default settings if set to ``False``.
To get the different date formats, instead of writing::
from django.utils.translation import get_date_formats
date_format, datetime_format, time_format = get_date_formats()
use::
from django.utils import formats
date_format = formats.get_format('DATE_FORMAT')
datetime_format = formats.get_format('DATETIME_FORMAT')
time_format = formats.get_format('TIME_FORMAT')
or, when directly formatting a date value::
from django.utils import formats
value_formatted = formats.date_format(value, 'DATETIME_FORMAT')
The same applies to the globals found in ``django.forms.fields``:
* ``DEFAULT_DATE_INPUT_FORMATS``
* ``DEFAULT_TIME_INPUT_FORMATS``
* ``DEFAULT_DATETIME_INPUT_FORMATS``
Use ``django.utils.formats.get_format()`` to get the appropriate formats.
What's new in Django 1.2 alpha 1
================================
The following new features are present as of this alpha release; this
release also marks the end of major feature development for the 1.2
release cycle. Some minor features will continue development until the
1.2 beta release, however.
CSRF support
------------
Django now has much improved protection against :doc:`Cross-Site
Request Forgery (CSRF) attacks</ref/contrib/csrf>`. This type of attack
occurs when a malicious Web site contains a link, a form button or
some javascript that is intended to perform some action on your Web
site, using the credentials of a logged-in user who visits the
malicious site in their browser. A related type of attack, 'login
CSRF', where an attacking site tricks a user's browser into logging
into a site with someone else's credentials, is also covered.
Email Backends
--------------
You can now :ref:`configure the way that Django sends email
<topic-email-backends>`. Instead of using SMTP to send all email, you
can now choose a configurable email backend to send messages. If your
hosting provider uses a sandbox or some other non-SMTP technique for
sending mail, you can now construct an email backend that will allow
Django's standard :doc:`mail sending methods</topics/email>` to use
those facilities.
This also makes it easier to debug mail sending - Django ships with
backend implementations that allow you to send email to a
:ref:`file<topic-email-file-backend>`, to the
:ref:`console<topic-email-console-backend>`, or to
:ref:`memory<topic-email-memory-backend>` - you can even configure all
email to be :ref:`thrown away<topic-email-dummy-backend>`.
Messages Framework
------------------
Django now includes a robust and configurable :doc:`messages framework
</ref/contrib/messages>` with built-in support for cookie- and session-based
messaging, for both anonymous and authenticated clients. The messages framework
replaces the deprecated user message API and allows you to temporarily store
messages in one request and retrieve them for display in a subsequent request
(usually the next one).
Support for multiple databases
------------------------------
Django 1.2 adds the ability to use :doc:`more than one database
</topics/db/multi-db>` in your Django project. Queries can be
issued at a specific database with the ``using()`` method on
querysets; individual objects can be saved to a specific database
by providing a ``using`` argument when you save the instance.
'Smart' if tag
--------------
The :ttag:`if` tag has been upgraded to be much more powerful. First, support
for comparison operators has been added. No longer will you have to type:
.. code-block:: html+django
{% ifnotequal a b %}
...
{% endifnotequal %}
...as you can now do:
.. code-block:: html+django
{% if a != b %}
...
{% endif %}
The operators supported are ``==``, ``!=``, ``<``, ``>``, ``<=``, ``>=`` and
``in``, all of which work like the Python operators, in addition to ``and``,
``or`` and ``not`` which were already supported.
Also, filters may now be used in the ``if`` expression. For example:
.. code-block:: html+django
<div
{% if user.email|lower == message.recipient|lower %}
class="highlight"
{% endif %}
>{{ message }}</div>
Template caching
----------------
In previous versions of Django, every time you rendered a template it
would be reloaded from disk. In Django 1.2, you can use a :ref:`cached
template loader <template-loaders>` to load templates once, then use
the cached result for every subsequent render. This can lead to a
significant performance improvement if your templates are broken into
lots of smaller subtemplates (using the ``{% extends %}`` or ``{%
include %}`` tags).
As a side effect, it is now much easier to support non-Django template
languages. For more details, see the :ref:`notes on supporting
non-Django template languages<topic-template-alternate-language>`.
Natural keys in fixtures
------------------------
Fixtures can refer to remote objects using
:ref:`topics-serialization-natural-keys`. This lookup scheme is an
alternative to the normal primary-key based object references in a
fixture, improving readability, and resolving problems referring to
objects whose primary key value may not be predictable or known.
``BigIntegerField``
-------------------
Models can now use a 64 bit :class:`~django.db.models.BigIntegerField` type.
Fast Failure for Tests
----------------------
The :djadmin:`test` subcommand of ``django-admin.py``, and the ``runtests.py``
script used to run Django's own test suite, support a new ``--failfast`` option.
When specified, this option causes the test runner to exit after encountering
a failure instead of continuing with the test run. In addition, the handling
of ``Ctrl-C`` during a test run has been improved to trigger a graceful exit
from the test run that reports details of the tests run before the interruption.
Improved localization
---------------------
Django's :doc:`internationalization framework </topics/i18n/index>` has been
expanded by locale aware formatting and form processing. That means, if
enabled, dates and numbers on templates will be displayed using the format
specified for the current locale. Django will also use localized formats
when parsing data in forms.
See :ref:`Format localization <format-localization>` for more details.
Added ``readonly_fields`` to ``ModelAdmin``
-------------------------------------------
:attr:`django.contrib.admin.ModelAdmin.readonly_fields` has been added to
enable non-editable fields in add/change pages for models and inlines. Field
and calculated values can be displayed alongside editable fields.
Customizable syntax highlighting
--------------------------------
You can now use the ``DJANGO_COLORS`` environment variable to modify
or disable the colors used by ``django-admin.py`` to provide
:ref:`syntax highlighting <syntax-coloring>`.
The Django 1.2 roadmap
======================
Before the final Django 1.2 release, several other preview/development
releases will be made available. The current schedule consists of at
least the following:
* Week of **January 26, 2010**: First Django 1.2 beta release. Final
feature freeze for Django 1.2.
* Week of **March 2, 2010**: First Django 1.2 release
candidate. String freeze for translations.
* Week of **March 9, 2010**: Django 1.2 final release.
If necessary, additional alpha, beta or release-candidate packages
will be issued prior to the final 1.2 release. Django 1.2 will be
released approximately one week after the final release candidate.
What you can do to help
=======================
In order to provide a high-quality 1.2 release, we need your help. Although this
alpha release is, again, *not* intended for production use, you can help the
Django team by trying out the alpha codebase in a safe test environment and
reporting any bugs or issues you encounter. The Django ticket tracker is the
central place to search for open issues:
* https://code.djangoproject.com/timeline
Please open new tickets if no existing ticket corresponds to a problem you're
running into.
Additionally, discussion of Django development, including progress toward the
1.2 release, takes place daily on the django-developers mailing list:
* http://groups.google.com/group/django-developers
... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
interested in helping out with Django's development, feel free to join the
discussions there.
Django's online documentation also includes pointers on how to contribute to
Django:
* :doc:`How to contribute to Django </internals/contributing/index>`
Contributions on any level -- developing code, writing documentation or simply
triaging tickets and helping to test proposed bugfixes -- are always welcome and
appreciated.
Development sprints for Django 1.2 will also be taking place at PyCon
US 2010, on the dedicated sprint days (February 22 through 25), and
anyone who wants to help out is welcome to join in, either in person
at PyCon or virtually in the IRC channel or on the mailing list.

173
docs/releases/1.2-beta-1.txt
View File

@ -1,173 +0,0 @@
===============================
Django 1.2 beta 1 release notes
===============================
February 5, 2010
Welcome to Django 1.2 beta 1!
This is the second in a series of preview/development releases leading
up to the eventual release of Django 1.2, currently scheduled to take
place in March 2010. This release is primarily targeted at developers
who are interested in trying out new features and testing the Django
codebase to help identify and resolve bugs prior to the final 1.2
release.
As such, this release is *not* intended for production use, and any
such use is discouraged.
This document covers changes since the Django 1.2 alpha release; the
:doc:`1.2 alpha release notes </releases/1.2-alpha-1>` cover new and
updated features in Django between 1.1 and 1.2 alpha.
Deprecations and other changes in 1.2 beta
==========================================
This beta release deprecates two portions of public API, and
introduces a potentially backwards-incompatible change to
another. Under :doc:`our API stability policy </misc/api-stability>`,
deprecation proceeds over multiple release cycles: initially, the
deprecated API will raise ``PendingDeprecationWarning``, followed by
raising ``DeprecationWarning`` in the next release, and finally
removal of the deprecated API in the release after that. APIs
beginning the deprecation process in Django 1.2 will be removed in the
Django 1.4 release.
Unit test runners
-----------------
Django 1.2 changes the test runner tools to use a class-based
approach. Old style function-based test runners will still work, but
should be updated to use the new :ref:`class-based runners
<topics-testing-test_runner>`.
Syndication feeds
-----------------
The ``django.contrib.syndication.feeds.Feed`` class is being
replaced by the :class:`django.contrib.syndication.views.Feed` class.
The old ``feeds.Feed`` class is deprecated. The new class has an
almost identical API, but allows instances to be used as views.
Also, in accordance with `RSS best practices`_, RSS feeds will now
include an ``atom:link`` element. You may need to update your tests to
take this into account.
For more information, see the full :doc:`syndication framework
documentation </ref/contrib/syndication>`.
.. _RSS best practices: http://www.rssboard.org/rss-profile
Cookie encoding
---------------
Due to cookie-handling bugs in Internet Explorer, Safari, and possibly
other browsers, Django's encoding of cookie values was changed so that
the characters comma (',') and semi-colon (';') are treated as
non-safe characters, and are therefore encoded as ``\054`` and
``\073`` respectively. This could produce backwards incompatibilities
if you are relying on the ability to set these characters directly in
cookie values.
What's new in 1.2 beta
======================
This 1.2 beta release marks the final feature freeze for Django 1.2;
while most feature development was completed for 1.2 alpha (which
constituted a freeze on major features), a few other new features were
added afterward and so are new as of 1.2 beta.
Object-level permissions
------------------------
A foundation for specifying permissions at the per-object level was
added in Django 1.2 alpha but not documented with the alpha release.
The default authentication backends shipped with Django do not
currently make use of this, but third-party authentication backends
are free to do so. See the :doc:`authentication docs </topics/auth/index>`
for more information.
Permissions for anonymous users
-------------------------------
If you provide a custom authentication backend with the attribute
``supports_anonymous_user`` set to ``True``, the ``AnonymousUser``
class will check the backend for permissions, just as the normal
``User`` does. This is intended to help centralize permission
handling; apps can always delegate the question of whether something
is allowed or not to the authorization/authentication system. See the
:doc:`authentication docs </topics/auth/index>` for more details.
``select_related()`` improvements
---------------------------------
The ``select_related()`` method of ``QuerySet`` now accepts the
``related_name`` of a reverse one-to-one relation in the list of
fields to select. One-to-one relations will not, however, be traversed
by a depth-based ``select_related()`` call.
The Django 1.2 roadmap
======================
Before the final Django 1.2 release, at least one additional
preview/development releases will be made available. The current
schedule consists of at least the following:
* Week of **March 2, 2010**: First Django 1.2 release
candidate. String freeze for translations.
* Week of **March 9, 2010**: Django 1.2 final release.
If necessary, additional beta or release-candidate packages will be
issued prior to the final 1.2 release. Django 1.2 will be released
approximately one week after the final release candidate.
What you can do to help
=======================
In order to provide a high-quality 1.2 release, we need your
help. Although this beta release is, again, *not* intended for
production use, you can help the Django team by trying out the beta
codebase in a safe test environment and reporting any bugs or issues
you encounter. The Django ticket tracker is the central place to
search for open issues:
* https://code.djangoproject.com/timeline
Please open new tickets if no existing ticket corresponds to a problem
you're running into.
Additionally, discussion of Django development, including progress
toward the 1.2 release, takes place daily on the django-developers
mailing list:
* http://groups.google.com/group/django-developers
... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
interested in helping out with Django's development, feel free to join the
discussions there.
Django's online documentation also includes pointers on how to
contribute to Django:
* :doc:`How to contribute to Django </internals/contributing/index>`
Contributions on any level -- developing code, writing documentation
or simply triaging tickets and helping to test proposed bugfixes --
are always welcome and appreciated.
Development sprints for Django 1.2 will also be taking place at PyCon
US 2010, on the dedicated sprint days (February 22 through 25), and
anyone who wants to help out is welcome to join in, either in person
at PyCon or virtually in the IRC channel or on the mailing list.

101
docs/releases/1.2-rc-1.txt
View File

@ -1,101 +0,0 @@
=============================
Django 1.2 RC 1 release notes
=============================
May 5, 2010
Welcome to the first Django 1.2 release candidate!
This is the third -- and likely last -- in a series of
preview/development releases leading up to the eventual release of
Django 1.2. This release is targeted primarily at developers who are
interested in trying out new features and testing the Django codebase
to help identify and resolve any critical bugs prior to the final 1.2
release.
As such, this release is not yet intended for production use, and any
such use is discouraged.
Django has been feature frozen since the 1.2 beta release, so this
release candidate contains no new features, only bugfixes; for a
summary of features new to Django 1.2, consult the :doc:`1.2 alpha
</releases/1.2-alpha-1>` and :doc:`1.2 beta </releases/1.2-beta-1>`
release notes.
Python compatibility
====================
While not a new feature, it's important to note that Django 1.2
introduces the first shift in our Python compatibility policy since
Django's initial public debut. Previous Django releases were tested
and supported on 2.x Python versions from 2.3 up; Django 1.2, however,
drops official support for Python 2.3. As such, the minimum Python
version required for Django is now 2.4, and Django is tested and
supported on Python 2.4, 2.5 and 2.6, and will be supported on the
as-yet-unreleased Python 2.7.
This change should affect only a small number of Django users, as most
operating-system vendors today are shipping Python 2.4 or newer as
their default version. If you're still using Python 2.3, however,
you'll need to stick to Django 1.1 until you can upgrade; per
:doc:`our support policy </internals/release-process>`, Django 1.1 will
continue to receive security support until the release of Django 1.3.
A roadmap for Django's overall 2.x Python support, and eventual
transition to Python 3.x, is currently being developed, and will be
announced prior to the release of Django 1.3.
The Django 1.2 roadmap
======================
As of this release candidate, Django 1.2 is in both feature freeze and
"string freeze" -- all strings marked for translation in the Django
codebase will retain their current form in the final Django 1.2
release. Only critical release-blocking bugs, documentation and
updated translation files will receive attention between now and the
final 1.2 release. Note that Django's localization infrastructure has
been expanded for 1.2, and translation packages should now include a
``formats.py`` file containing data for localized formatting of
numbers and dates.
If no critical bugs are discovered, Django 1.2 will be released
approximately one week after this release candidate, on or about May
12, 2010.
What you can do to help
=======================
In order to provide a high-quality 1.2 release, we need your
help. Although this release candidate is, again, *not* intended for
production use, you can help the Django team by trying out this
release candidate in a safe testing environment and reporting any bugs
or issues you encounter. The Django ticket tracker is the central
place to search for open issues:
* https://code.djangoproject.com/timeline
Please open a new ticket only if no existing ticket corresponds to a
problem you're running into.
Additionally, discussion of Django development, including progress
toward the 1.2 release, takes place daily on the django-developers
mailing list:
* http://groups.google.com/group/django-developers
... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
interested in helping out with Django's development, feel free to join the
discussions there.
Django's online documentation also includes pointers on how to contribute to
Django:
* :doc:`How to contribute to Django </internals/contributing/index>`
Contributions on any level -- developing code, writing documentation or simply
triaging tickets and helping to test proposed bugfixes -- are always welcome and
appreciated.

397
docs/releases/1.3-alpha-1.txt
View File

@ -1,397 +0,0 @@
================================
Django 1.3 alpha 1 release notes
================================
November 11, 2010
Welcome to Django 1.3 alpha 1!
This is the first in a series of preview/development releases leading
up to the eventual release of Django 1.3. This release is primarily
targeted at developers who are interested in trying out new features
and testing the Django codebase to help identify and resolve bugs
prior to the final 1.3 release.
As such, this release is *not* intended for production use, and any such use is
discouraged.
As of this alpha release, Django 1.3 contains a number of nifty `new
features`_, lots of bug fixes, some minor `backwards incompatible
changes`_ and an easy upgrade path from Django 1.2.
.. _new features: `What's new in Django 1.3 alpha 1`_
.. _backwards incompatible changes: backwards-incompatible-changes-1.3-alpha-1_
What's new in Django 1.3 alpha 1
================================
Class-based views
~~~~~~~~~~~~~~~~~
Django 1.3 adds a framework that allows you to use a class as a view.
This means you can compose a view out of a collection of methods that
can be subclassed and overridden to provide common views of data without
having to write too much code.
Analogs of all the old function-based generic views have been provided,
along with a completely generic view base class that can be used as
the basis for reusable applications that can be easily extended.
See :doc:`the documentation on Class-based Generic Views
</topics/class-based-views/index>` for more details. There is also a document to
help you `convert your function-based generic views to class-based
views <https://docs.djangoproject.com/en/1.4/topics/generic-views-migration/>`_.
Logging
~~~~~~~
Django 1.3 adds framework-level support for Python's logging module.
This means you can now easily configure and control logging as part of
your Django project. A number of logging handlers and logging calls
have been added to Django's own code as well -- most notably, the
error emails sent on a HTTP 500 server error are now handled as a
logging activity. See :doc:`the documentation on Django's logging
interface </topics/logging>` for more details.
Extended static files handling
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django 1.3 ships with a new contrib app ``'django.contrib.staticfiles'``
to help developers handle the static media files (images, CSS, Javascript,
etc.) that are needed to render a complete web page.
In previous versions of Django, it was common to place static assets
in :setting:`MEDIA_ROOT` along with user-uploaded files, and serve
them both at :setting:`MEDIA_URL`. Part of the purpose of introducing
the ``staticfiles`` app is to make it easier to keep static files
separate from user-uploaded files. Static assets should now go in
``static/`` subdirectories of your apps or in other static assets
directories listed in :setting:`STATICFILES_DIRS`, and will be served
at :setting:`STATIC_URL`.
See the :doc:`reference documentation of the app </ref/contrib/staticfiles>`
for more details or learn how to :doc:`manage static files
</howto/static-files/index>`.
``unittest2`` support
~~~~~~~~~~~~~~~~~~~~~
Python 2.7 introduced some major changes to the unittest library,
adding some extremely useful features. To ensure that every Django
project can benefit from these new features, Django ships with a
copy of unittest2_, a copy of the Python 2.7 unittest library,
backported for Python 2.4 compatibility.
To access this library, Django provides the
``django.utils.unittest`` module alias. If you are using Python
2.7, or you have installed unittest2 locally, Django will map the
alias to the installed version of the unittest library. Otherwise,
Django will use its own bundled version of unittest2.
To use this alias, simply use::
from django.utils import unittest
wherever you would have historically used::
import unittest
If you want to continue to use the base unittest library, you can --
you just won't get any of the nice new unittest2 features.
.. _unittest2: http://pypi.python.org/pypi/unittest2
Transaction context managers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Users of Python 2.5 and above may now use transaction management functions as
`context managers`_. For example::
with transaction.autocommit():
# ...
.. _context managers: http://docs.python.org/glossary.html#term-context-manager
Configurable delete-cascade
~~~~~~~~~~~~~~~~~~~~~~~~~~~
:class:`~django.db.models.ForeignKey` and
:class:`~django.db.models.OneToOneField` now accept an
:attr:`~django.db.models.ForeignKey.on_delete` argument to customize behavior
when the referenced object is deleted. Previously, deletes were always
cascaded; available alternatives now include set null, set default, set to any
value, protect, or do nothing.
For more information, see the :attr:`~django.db.models.ForeignKey.on_delete`
documentation.
Contextual markers in translatable strings
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For translation strings with ambiguous meaning, you can now
use the ``pgettext`` function to specify the context of the string.
For more information, see :ref:`contextual-markers`
Everything else
~~~~~~~~~~~~~~~
Django :doc:`1.1 <1.1>` and :doc:`1.2 <1.2>` added
lots of big ticket items to Django, like multiple-database support,
model validation, and a session-based messages framework. However,
this focus on big features came at the cost of lots of smaller
features.
To compensate for this, the focus of the Django 1.3 development
process has been on adding lots of smaller, long standing feature
requests. These include:
* Improved tools for accessing and manipulating the current Site via
``django.contrib.sites.models.get_current_site()``.
* A :class:`~django.test.RequestFactory` for mocking
requests in tests.
* A new test assertion --
:meth:`~django.test.TransactionTestCase.assertNumQueries` -- making it
easier to test the database activity associated with a view.
.. _backwards-incompatible-changes-1.3-alpha-1:
Backwards-incompatible changes in 1.3 alpha 1
=============================================
PasswordInput default rendering behavior
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The :class:`~django.forms.PasswordInput` form widget, intended for use
with form fields which represent passwords, accepts a boolean keyword
argument ``render_value`` indicating whether to send its data back to
the browser when displaying a submitted form with errors. Prior to
Django 1.3, this argument defaulted to ``True``, meaning that the
submitted password would be sent back to the browser as part of the
form. Developers who wished to add a bit of additional security by
excluding that value from the redisplayed form could instantiate a
:class:`~django.forms.PasswordInput` passing ``render_value=False`` .
Due to the sensitive nature of passwords, however, Django 1.3 takes
this step automatically; the default value of ``render_value`` is now
``False``, and developers who want the password value returned to the
browser on a submission with errors (the previous behavior) must now
explicitly indicate this. For example::
class LoginForm(forms.Form):
username = forms.CharField(max_length=100)
password = forms.CharField(widget=forms.PasswordInput(render_value=True))
Clearable default widget for FileField
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django 1.3 now includes a ``ClearableFileInput`` form widget in addition to
``FileInput``. ``ClearableFileInput`` renders with a checkbox to clear the
field's value (if the field has a value and is not required); ``FileInput``
provided no means for clearing an existing file from a ``FileField``.
``ClearableFileInput`` is now the default widget for a ``FileField``, so
existing forms including ``FileField`` without assigning a custom widget will
need to account for the possible extra checkbox in the rendered form output.
To return to the previous rendering (without the ability to clear the
``FileField``), use the ``FileInput`` widget in place of
``ClearableFileInput``. For instance, in a ``ModelForm`` for a hypothetical
``Document`` model with a ``FileField`` named ``document``::
from django import forms
from myapp.models import Document
class DocumentForm(forms.ModelForm):
class Meta:
model = Document
widgets = {'document': forms.FileInput}
New index on database session table
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Prior to Django 1.3, the database table used by the database backend
for the :doc:`sessions </topics/http/sessions>` app had no index on
the ``expire_date`` column. As a result, date-based queries on the
session table -- such as the query that is needed to purge old
sessions -- would be very slow if there were lots of sessions.
If you have an existing project that is using the database session
backend, you don't have to do anything to accommodate this change.
However, you may get a significant performance boost if you manually
add the new index to the session table. The SQL that will add the
index can be found by running the :djadmin:`sqlindexes` admin
command::
python manage.py sqlindexes sessions
No more naughty words
~~~~~~~~~~~~~~~~~~~~~
Django has historically provided (and enforced) a list of profanities.
The :doc:`comments app </ref/contrib/comments/index>` has enforced this
list of profanities, preventing people from submitting comments that
contained one of those profanities.
Unfortunately, the technique used to implement this profanities list
was woefully naive, and prone to the `Scunthorpe problem`_. Fixing the
built in filter to fix this problem would require significant effort,
and since natural language processing isn't the normal domain of a web
framework, we have "fixed" the problem by making the list of
prohibited words an empty list.
If you want to restore the old behavior, simply put a
:setting:`PROFANITIES_LIST` setting in your settings file that includes the
words that you want to prohibit (see the `commit that implemented this
change`_ if you want to see the list of words that was historically
prohibited). However, if avoiding profanities is important to you, you
would be well advised to seek out a better, less naive approach to the
problem.
.. _Scunthorpe problem: http://en.wikipedia.org/wiki/Scunthorpe_problem
.. _commit that implemented this change: https://code.djangoproject.com/changeset/13996
Localflavor changes
~~~~~~~~~~~~~~~~~~~
Django 1.3 introduces the following backwards-incompatible changes to
local flavors:
* Indonesia (id) -- The province "Nanggroe Aceh Darussalam (NAD)"
has been removed from the province list in favor of the new
official designation "Aceh (ACE)".
Features deprecated in 1.3
==========================
Django 1.3 deprecates some features from earlier releases.
These features are still supported, but will be gradually phased out
over the next few release cycles.
Code taking advantage of any of the features below will raise a
``PendingDeprecationWarning`` in Django 1.3. This warning will be
silent by default, but may be turned on using Python's :mod:`warnings`
module, or by running Python with a ``-Wd`` or ``-Wall`` flag.
In Django 1.4, these warnings will become a ``DeprecationWarning``,
which is *not* silent. In Django 1.5 support for these features will
be removed entirely.
.. seealso::
For more details, see the documentation :doc:`Django's release process
</internals/release-process>` and our :doc:`deprecation timeline
</internals/deprecation>`.
``mod_python`` support
~~~~~~~~~~~~~~~~~~~~~~
The ``mod_python`` library has not had a release since 2007 or a commit since
2008. The Apache Foundation board voted to remove ``mod_python`` from the set
of active projects in its version control repositories, and its lead developer
has shifted all of his efforts toward the lighter, slimmer, more stable, and
more flexible ``mod_wsgi`` backend.
If you are currently using the ``mod_python`` request handler, you are strongly
encouraged to redeploy your Django instances using :doc:`mod_wsgi
</howto/deployment/wsgi/modwsgi>`.
Function-based generic views
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As a result of the introduction of class-based generic views, the
function-based generic views provided by Django have been deprecated.
The following modules and the views they contain have been deprecated:
* ``django.views.generic.create_update``
* ``django.views.generic.date_based``
* ``django.views.generic.list_detail``
* ``django.views.generic.simple``
Test client response ``template`` attribute
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django's :ref:`test client <test-client>` returns
:class:`~django.test.Response` objects annotated with extra testing
information. In Django versions prior to 1.3, this included a ``template``
attribute containing information about templates rendered in generating the
response: either None, a single :class:`~django.template.Template` object, or a
list of :class:`~django.template.Template` objects. This inconsistency in
return values (sometimes a list, sometimes not) made the attribute difficult
to work with.
In Django 1.3 the ``template`` attribute is deprecated in favor of a new
:attr:`~django.test.Response.templates` attribute, which is always a
list, even if it has only a single element or no elements.
``DjangoTestRunner``
~~~~~~~~~~~~~~~~~~~~
As a result of the introduction of support for unittest2, the features
of ``django.test.simple.DjangoTestRunner`` (including fail-fast
and Ctrl-C test termination) have been made redundant. In view of this
redundancy, ``DjangoTestRunner`` has been turned into an empty placeholder
class, and will be removed entirely in Django 1.5.
The Django 1.3 roadmap
======================
Before the final Django 1.3 release, several other preview/development
releases will be made available. The current schedule consists of at
least the following:
* Week of **November 29, 2010**: First Django 1.3 beta release. Final
feature freeze for Django 1.3.
* Week of **January 10, 2011**: First Django 1.3 release
candidate. String freeze for translations.
* Week of **January 17, 2011**: Django 1.3 final release.
If necessary, additional alpha, beta or release-candidate packages
will be issued prior to the final 1.3 release. Django 1.3 will be
released approximately one week after the final release candidate.
What you can do to help
=======================
In order to provide a high-quality 1.3 release, we need your help. Although this
alpha release is, again, *not* intended for production use, you can help the
Django team by trying out the alpha codebase in a safe test environment and
reporting any bugs or issues you encounter. The Django ticket tracker is the
central place to search for open issues:
* https://code.djangoproject.com/timeline
Please open new tickets if no existing ticket corresponds to a problem you're
running into.
Additionally, discussion of Django development, including progress toward the
1.3 release, takes place daily on the django-developers mailing list:
* http://groups.google.com/group/django-developers
... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
interested in helping out with Django's development, feel free to join the
discussions there.
Django's online documentation also includes pointers on how to contribute to
Django:
* :doc:`How to contribute to Django </internals/contributing/index>`
Contributions on any level -- developing code, writing documentation or simply
triaging tickets and helping to test proposed bugfixes -- are always welcome and
appreciated.
Several development sprints will also be taking place before the 1.3
release; these will typically be announced in advance on the
django-developers mailing list, and anyone who wants to help is
welcome to join in.

231
docs/releases/1.3-beta-1.txt
View File

@ -1,231 +0,0 @@
================================
Django 1.3 beta 1 release notes
================================
Welcome to Django 1.3 beta 1!
This is the second in a series of preview/development releases leading
up to the eventual release of Django 1.3. This release is primarily
targeted at developers who are interested in trying out new features
and testing the Django codebase to help identify and resolve bugs
prior to the final 1.3 release.
As such, this release is *not* intended for production use, and any such use
is discouraged.
What's new in Django 1.3 beta 1
===============================
Further tweaks to the staticfiles app
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django 1.3 ships with a new contrib app :mod:`django.contrib.staticfiles`
to help developers handle the static media files (images, CSS, JavaScript,
etc.) that are needed to render a complete web page.
The :mod:`~django.contrib.staticfiles` app ships with the ability to
automatically serve static files during development (if the :setting:`DEBUG`
setting is ``True``) when using the :djadmin:`runserver` management command.
Based on feedback from the community this release adds two new options to the
:djadmin:`runserver` command to modify this behavior:
* ``--nostatic``: prevents the :djadmin:`runserver` command from serving
files completely.
* ``--insecure``: enables serving of static files even if running with
:setting:`DEBUG` set to False. (This is **not** recommended!)
See the :doc:`staticfiles reference documentation </ref/contrib/staticfiles>`
for more details, or learn :doc:`how to manage static files
</howto/static-files/index>`.
Translation comments
~~~~~~~~~~~~~~~~~~~~
If you would like to give translators hints about a translatable string, you
can add a comment prefixed with the ``Translators`` keyword on the line
preceding the string, e.g.::
def my_view(request):
# Translators: This message appears on the home page only
output = ugettext("Welcome to my site.")
The comment will appear in the resulting .po file and should also be
displayed by most translation tools.
For more information, see :ref:`translator-comments`.
Permissions for inactive users
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you provide a custom auth backend with ``supports_inactive_user`` set to
``True``, an inactive user model will check the backend for permissions.
This is useful for further centralizing the permission handling. See the
:doc:`authentication docs </topics/auth/index>` for more details.
Backwards-incompatible changes in 1.3 alpha 2
=============================================
Change to admin lookup filters
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Django admin has long had an undocumented "feature" allowing savvy
users to manipulate the query string of changelist pages to filter the
list of objects displayed. However, this also creates a security
issue, as a staff user with sufficient knowledge of model structure
could use this "feature" to gain access to information not normally accessible.
As a result, changelist filtering now explicitly validates all lookup
arguments in the query string, and permits only fields which are
directly on the model, or relations explicitly permitted by the
``ModelAdmin`` definition. If you were relying on this undocumented
feature, you will need to update your ``ModelAdmin`` definitions to
whitelist the relations you choose to expose for filtering.
Introduction of STATIC_URL and STATIC_ROOT settings
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The newly introduced :mod:`~django.contrib.staticfiles` app -- which extends
Django's abilities to handle static files for apps and projects -- required the
addition of two new settings to refer to those files in templates and code,
especially in contrast to the :setting:`MEDIA_URL` and :setting:`MEDIA_ROOT`
settings that refer to user-uploaded files.
Prior to 1.3 alpha 2 these settings were called ``STATICFILES_URL`` and
``STATICFILES_ROOT`` to follow the naming scheme for app-centric settings.
Based on feedback from the community it became apparent that those settings
created confusion, especially given the fact that handling static files is also
desired outside the use of the optional :mod:`~django.contrib.staticfiles` app.
As a result, we took the following steps to rectify the issue:
* Two new global settings were added that will be used by, **but are not
limited to**, the :doc:`staticfiles</ref/contrib/staticfiles>` app:
* :setting:`STATIC_ROOT` (formally ``STATICFILES_ROOT``)
* :setting:`STATIC_URL` (formally ``STATICFILES_URL``)
* The ``django.contrib.staticfiles.templatetags.staticfiles.get_staticfiles_prefix``
template tag was moved to Django's core (``django.templatetags.static``) and
renamed to :ttag:`get_static_prefix`.
* The ``django.contrib.staticfiles.context_processors.staticfiles``
context processor was moved to Django's core
(``django.core.context_processors.static``) and renamed to
:func:`~django.core.context_processors.static`.
* :ref:`form-asset-paths` now uses :setting:`STATIC_URL` as the prefix
**if the value is not None**, and falls back to the previously used
:setting:`MEDIA_URL` setting otherwise.
Changes to the login methods of the admin
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In previous version the admin app defined login methods in multiple locations
and ignored the almost identical implementation in the already used auth app.
A side effect of this duplication was the missing adoption of the changes made
in r12634_ to support a broader set of characters for usernames.
This release refactors the admin's login mechanism to use a subclass of the
:class:`~django.contrib.auth.forms.AuthenticationForm` instead of a manual
form validation. The previously undocumented method
``'django.contrib.admin.sites.AdminSite.display_login_form'`` has been removed
in favor of a new :attr:`~django.contrib.admin.AdminSite.login_form`
attribute.
.. _r12634: https://code.djangoproject.com/changeset/12634
Changes to ``USStateField``
===========================
The ``django.contrib.localflavor`` application contains collections
of code relevant to specific countries or cultures. One such is
``USStateField``, which provides a field for storing the two-letter postal
abbreviation of a U.S. state. This field has consistently caused problems,
however, because it is often used to store the state portion of a U.S postal
address, but not all "states" recognized by the U.S Postal Service are
actually states of the U.S. or even U.S. territory. Several
compromises over the list of choices resulted in some users feeling
the field supported too many locations, while others felt it supported
too few.
In Django 1.3 we're taking a new approach to this problem, implemented
as a pair of changes:
* The choice list for ``USStateField`` has changed. Previously, it
consisted of the 50 U.S. states, the District of Columbia and
U.S. overseas territories. As of Django 1.3 it includes all previous
choices, plus the U.S. Armed Forces postal codes.
* A new model field,
``django.contrib.localflavor.us.models.USPostalCodeField``, has
been added which draws its choices from a list of all postal
abbreviations recognized by the U.S Postal Service. This includes
all abbreviations recognized by ``USStateField``, plus three
independent nations -- the Federated States of Micronesia, the
Republic of the Marshall Islands and the Republic of Palau -- which
are serviced under treaty by the U.S. postal system. A new form
widget, ``django.contrib.localflavor.us.forms.USPSSelect``, is
also available and provides the same set of choices.
Additionally, several finer-grained choice tuples are provided which
allow mixing and matching of subsets of the U.S. states and
territories, and other locations serviced by the U.S. postal
system. Consult the ``django.contrib.localflavor`` documentation
for more details.
The change to ``USStateField`` is technically backwards-incompatible for
users who expect this field to exclude Armed Forces locations. If you
need to support U.S. mailing addresses without Armed Forces locations,
see the list of choice tuples available in the localflavor
documentation.
The Django 1.3 roadmap
======================
Before the final Django 1.3 release, several other preview/development
releases will be made available. The current schedule consists of at
least the following:
* Week of **January 24, 2011**: First Django 1.3 release
candidate. String freeze for translations.
* Week of **January 31, 2011**: Django 1.3 final release.
If necessary, additional beta or release-candidate packages
will be issued prior to the final 1.3 release. Django 1.3 will be
released approximately one week after the final release candidate.
What you can do to help
=======================
In order to provide a high-quality 1.3 release, we need your help. Although this
beta release is, again, *not* intended for production use, you can help the
Django team by trying out the beta codebase in a safe test environment and
reporting any bugs or issues you encounter. The Django ticket tracker is the
central place to search for open issues:
* https://code.djangoproject.com/timeline
Please open new tickets if no existing ticket corresponds to a problem you're
running into.
Additionally, discussion of Django development, including progress toward the
1.3 release, takes place daily on the django-developers mailing list:
* http://groups.google.com/group/django-developers
... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
interested in helping out with Django's development, feel free to join the
discussions there.
Django's online documentation also includes pointers on how to contribute to
Django:
* :doc:`How to contribute to Django </internals/contributing/index>`
Contributions on any level -- developing code, writing documentation or simply
triaging tickets and helping to test proposed bugfixes -- are always welcome and
appreciated.

1125
docs/releases/1.4-alpha-1.txt
View File

File diff suppressed because it is too large Load Diff

1197
docs/releases/1.4-beta-1.txt
View File

File diff suppressed because it is too large Load Diff

634
docs/releases/1.5-alpha-1.txt
View File

@ -1,634 +0,0 @@
==============================
Django 1.5 alpha release notes
==============================
October 25, 2012.
Welcome to Django 1.5 alpha!
This is the first in a series of preview/development releases leading up to the
eventual release of Django 1.5, scheduled for December 2012. This release is
primarily targeted at developers who are interested in trying out new features
and testing the Django codebase to help identify and resolve bugs prior to the
final 1.5 release.
As such, this release is *not* intended for production use, and any such use
is discouraged.
In particular, we need the community's help to test Django 1.5's new `Python 3
support`_ -- not just to report bugs on Python 3, but also regressions on Python
2. While Django is very conservative with regards to backwards compatibility,
mistakes are always possible, and it's likely that the Python 3 refactoring work
introduced some regressions.
Django 1.5 alpha includes various `new features`_ and some minor `backwards
incompatible changes`_. There are also some features that have been dropped,
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.5`_
.. _`backwards incompatible changes`: `Backwards incompatible changes in 1.5`_
.. _`begun the deprecation process for some features`: `Features deprecated in 1.5`_
Overview
========
The biggest new feature in Django 1.5 is the `configurable User model`_. Before
Django 1.5, applications that wanted to use Django's auth framework
(:mod:`django.contrib.auth`) were forced to use Django's definition of a "user".
In Django 1.5, you can now swap out the ``User`` model for one that you write
yourself. This could be a simple extension to the existing ``User`` model -- for
example, you could add a Twitter or Facebook ID field -- or you could completely
replace the ``User`` with one totally customized for your site.
Django 1.5 is also the first release with `Python 3 support`_! We're labeling
this support "experimental" because we don't yet consider it production-ready,
but everything's in place for you to start porting your apps to Python 3.
Our next release, Django 1.6, will support Python 3 without reservations.
Other notable new features in Django 1.5 include:
* `Support for saving a subset of model's fields`_ -
:meth:`Model.save() <django.db.models.Model.save()>` now accepts an
``update_fields`` argument, letting you specify which fields are
written back to the database when you call ``save()``. This can help
in high-concurrency operations, and can improve performance.
* Better `support for streaming responses <#explicit-streaming-responses>`_ via
the new :class:`~django.http.StreamingHttpResponse` response class.
* `GeoDjango`_ now supports PostGIS 2.0.
* ... and more; `see below <#what-s-new-in-django-1-5>`_.
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.5 ships with some minor
`backwards incompatible changes`_; people upgrading from previous versions
of Django should read that list carefully.
One deprecated feature worth noting is the shift to "new-style" :ttag:`url` tag.
Prior to Django 1.3, syntax like ``{% url myview %}`` was interpreted
incorrectly (Django considered ``"myview"`` to be a literal name of a view, not
a template variable named ``myview``). Django 1.3 and above introduced the
``{% load url from future %}`` syntax to bring in the corrected behavior where
``myview`` was seen as a variable.
The upshot of this is that if you are not using ``{% load url from future %}``
in your templates, you'll need to change tags like ``{% url myview %}`` to
``{% url "myview" %}``. If you *were* using ``{% load url from future %}`` you
can simply remove that line under Django 1.5
Python compatibility
====================
Django 1.5 requires Python 2.6.5 or above, though we **highly recommended**
Python 2.7.3 or above. Support for Python 2.5 and below has been dropped.
This change should affect only a small number of Django users, as most
operating-system vendors today are shipping Python 2.6 or newer as their default
version. If you're still using Python 2.5, however, you'll need to stick to
Django 1.4 until you can upgrade your Python version. Per :doc:`our support
policy </internals/release-process>`, Django 1.4 will continue to receive
security support until the release of Django 1.6.
Django 1.5 does not run on a Jython final release, because Jython's latest
release doesn't currently support Python 2.6. However, Jython currently does
offer an alpha release featuring 2.7 support, and Django 1.5 supports that alpha
release.
Python 3 support
~~~~~~~~~~~~~~~~
Django 1.5 introduces support for Python 3 - specifically, Python
3.2 and above. This comes in the form of a **single** codebase; you don't
need to install a different version of Django on Python 3. This means that
you can write application targeted for just Python 2, just Python 3, or single
applications that support both platforms.
However, we're labeling this support "experimental" for now: although it's
received extensive testing via our automated test suite, it's received very
little real-world testing. We've done our best to eliminate bugs, but we can't
be sure we covered all possible uses of Django. Further, Django's more than a
web framework; it's an ecosystem of pluggable components. At this point, very
few third-party applications have been ported to Python 3, so it's unlikely
that a real-world application will have all its dependencies satisfied under
Python 3.
Thus, we're recommending that Django 1.5 not be used in production under Python
3. Instead, use this opportunity to begin :doc:`porting applications to Python 3
</topics/python3>`. If you're an author of a pluggable component, we encourage you
to start porting now.
We plan to offer first-class, production-ready support for Python 3 in our next
release, Django 1.6.
What's new in Django 1.5
========================
Configurable User model
~~~~~~~~~~~~~~~~~~~~~~~
In Django 1.5, you can now use your own model as the store for user-related
data. If your project needs a username with more than 30 characters, or if
you want to store usernames in a format other than first name/last name, or
you want to put custom profile information onto your User object, you can
now do so.
If you have a third-party reusable application that references the User model,
you may need to make some changes to the way you reference User instances. You
should also document any specific features of the User model that your
application relies upon.
See the :ref:`documentation on custom User models <auth-custom-user>` for
more details.
Support for saving a subset of model's fields
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The method :meth:`Model.save() <django.db.models.Model.save()>` has a new
keyword argument ``update_fields``. By using this argument it is possible to
save only a select list of model's fields. This can be useful for performance
reasons or when trying to avoid overwriting concurrent changes.
Deferred instances (those loaded by .only() or .defer()) will automatically
save just the loaded fields. If any field is set manually after load, that
field will also get updated on save.
See the :meth:`Model.save() <django.db.models.Model.save()>` documentation for
more details.
Caching of related model instances
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When traversing relations, the ORM will avoid re-fetching objects that were
previously loaded. For example, with the tutorial's models::
>>> first_poll = Poll.objects.all()[0]
>>> first_choice = first_poll.choice_set.all()[0]
>>> first_choice.poll is first_poll
True
In Django 1.5, the third line no longer triggers a new SQL query to fetch
``first_choice.poll``; it was set by the second line.
For one-to-one relationships, both sides can be cached. For many-to-one
relationships, only the single side of the relationship can be cached. This
is particularly helpful in combination with ``prefetch_related``.
Explicit support for streaming responses
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Before Django 1.5, it was possible to create a streaming response by passing
an iterator to :class:`~django.http.HttpResponse`. But this was unreliable:
any middleware that accessed the :attr:`~django.http.HttpResponse.content`
attribute would consume the iterator prematurely.
You can now explicitly generate a streaming response with the new
:class:`~django.http.StreamingHttpResponse` class. This class exposes a
:class:`~django.http.StreamingHttpResponse.streaming_content` attribute which
is an iterator.
Since :class:`~django.http.StreamingHttpResponse` does not have a ``content``
attribute, middleware that needs access to the response content must test for
streaming responses and behave accordingly. See :ref:`response-middleware` for
more information.
``{% verbatim %}`` template tag
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To make it easier to deal with javascript templates which collide with Django's
syntax, you can now use the :ttag:`verbatim` block tag to avoid parsing the
tag's content.
Retrieval of ``ContentType`` instances associated with proxy models
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The methods :meth:`ContentTypeManager.get_for_model() <django.contrib.contenttypes.models.ContentTypeManager.get_for_model()>`
and :meth:`ContentTypeManager.get_for_models() <django.contrib.contenttypes.models.ContentTypeManager.get_for_models()>`
have a new keyword argument – respectively ``for_concrete_model`` and ``for_concrete_models``.
By passing ``False`` using this argument it is now possible to retrieve the
:class:`ContentType <django.contrib.contenttypes.models.ContentType>`
associated with proxy models.
New ``view`` variable in class-based views context
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In all :doc:`generic class-based views </topics/class-based-views/index>`
(or any class-based view inheriting from ``ContextMixin``), the context dictionary
contains a ``view`` variable that points to the ``View`` instance.
GeoDjango
~~~~~~~~~
* :class:`~django.contrib.gis.geos.LineString` and
:class:`~django.contrib.gis.geos.MultiLineString` GEOS objects now support the
:meth:`~django.contrib.gis.geos.GEOSGeometry.interpolate()` and
:meth:`~django.contrib.gis.geos.GEOSGeometry.project()` methods
(so-called linear referencing).
* The ``wkb`` and ``hex`` properties of
:class:`~django.contrib.gis.geos.GEOSGeometry` objects preserve the Z
dimension.
* Support for PostGIS 2.0 has been added and support for GDAL < 1.5 has been
dropped.
Minor features
~~~~~~~~~~~~~~
Django 1.5 also includes several smaller improvements worth noting:
* The template engine now interprets ``True``, ``False`` and ``None`` as the
corresponding Python objects.
* :mod:`django.utils.timezone` provides a helper for converting aware
datetimes between time zones. See :func:`~django.utils.timezone.localtime`.
* The generic views support OPTIONS requests.
* Management commands do not raise ``SystemExit`` any more when called by code
from :ref:`call_command <call-command>`. Any exception raised by the command
(mostly :ref:`CommandError <ref-command-exceptions>`) is propagated.
* The dumpdata management command outputs one row at a time, preventing
out-of-memory errors when dumping large datasets.
* In the localflavor for Canada, "pq" was added to the acceptable codes for
Quebec. It's an old abbreviation.
* The :ref:`receiver <connecting-receiver-functions>` decorator is now able to
connect to more than one signal by supplying a list of signals.
* In the admin, you can now filter users by groups which they are members of.
* :meth:`QuerySet.bulk_create()
<django.db.models.query.QuerySet.bulk_create>` now has a batch_size
argument. By default the batch_size is unlimited except for SQLite where
single batch is limited so that 999 parameters per query isn't exceeded.
* The :setting:`LOGIN_URL` and :setting:`LOGIN_REDIRECT_URL` settings now also
accept view function names and
:ref:`named URL patterns <naming-url-patterns>`. This allows you to reduce
configuration duplication. More information can be found in the
:func:`~django.contrib.auth.decorators.login_required` documentation.
* Django now provides a mod_wsgi :doc:`auth handler
</howto/deployment/wsgi/apache-auth>`.
* The :meth:`QuerySet.delete() <django.db.models.query.QuerySet.delete>`
and :meth:`Model.delete() <django.db.models.Model.delete()>` can now take
fast-path in some cases. The fast-path allows for less queries and less
objects fetched into memory. See :meth:`QuerySet.delete()
<django.db.models.query.QuerySet.delete>` for details.
* An instance of :class:`~django.core.urlresolvers.ResolverMatch` is stored on
the request as ``resolver_match``.
* By default, all logging messages reaching the ``django`` logger when
:setting:`DEBUG` is ``True`` are sent to the console (unless you redefine the
logger in your :setting:`LOGGING` setting).
* When using :class:`~django.template.RequestContext`, it is now possible to
look up permissions by using ``{% if 'someapp.someperm' in perms %}``
in templates.
* It's not required any more to have ``404.html`` and ``500.html`` templates in
the root templates directory. Django will output some basic error messages for
both situations when those templates are not found. Of course, it's still
recommended as good practice to provide those templates in order to present
pretty error pages to the user.
* :mod:`django.contrib.auth` provides a new signal that is emitted
whenever a user fails to login successfully. See
:data:`~django.contrib.auth.signals.user_login_failed`
* The loaddata management command now supports an
:djadminopt:`--ignorenonexistent` option to ignore data for fields that no
longer exist.
* :meth:`~django.test.SimpleTestCase.assertXMLEqual` and
:meth:`~django.test.SimpleTestCase.assertXMLNotEqual` new assertions allow
you to test equality for XML content at a semantic level, without caring for
syntax differences (spaces, attribute order, etc.).
Backwards incompatible changes in 1.5
=====================================
.. 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.
Context in year archive class-based views
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For consistency with the other date-based generic views,
:class:`~django.views.generic.dates.YearArchiveView` now passes ``year`` in
the context as a :class:`datetime.date` rather than a string. If you are
using ``{{ year }}`` in your templates, you must replace it with ``{{
year|date:"Y" }}``.
``next_year`` and ``previous_year`` were also added in the context. They are
calculated according to ``allow_empty`` and ``allow_future``.
Context in year and month archive class-based views
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:class:`~django.views.generic.dates.YearArchiveView` and
:class:`~django.views.generic.dates.MonthArchiveView` were documented to
provide a ``date_list`` sorted in ascending order in the context, like their
function-based predecessors, but it actually was in descending order. In 1.5,
the documented order was restored. You may want to add (or remove) the
``reversed`` keyword when you're iterating on ``date_list`` in a template::
{% for date in date_list reversed %}
:class:`~django.views.generic.dates.ArchiveIndexView` still provides a
``date_list`` in descending order.
Context in TemplateView
~~~~~~~~~~~~~~~~~~~~~~~
For consistency with the design of the other generic views,
:class:`~django.views.generic.base.TemplateView` no longer passes a ``params``
dictionary into the context, instead passing the variables from the URLconf
directly into the context.
Non-form data in HTTP requests
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:attr:`request.POST <django.http.HttpRequest.POST>` will no longer include data
posted via HTTP requests with non form-specific content-types in the header.
In prior versions, data posted with content-types other than
``multipart/form-data`` or ``application/x-www-form-urlencoded`` would still
end up represented in the :attr:`request.POST <django.http.HttpRequest.POST>`
attribute. Developers wishing to access the raw POST data for these cases,
should use the :attr:`request.body <django.http.HttpRequest.body>` attribute
instead.
OPTIONS, PUT and DELETE requests in the test client
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Unlike GET and POST, these HTTP methods aren't implemented by web browsers.
Rather, they're used in APIs, which transfer data in various formats such as
JSON or XML. Since such requests may contain arbitrary data, Django doesn't
attempt to decode their body.
However, the test client used to build a query string for OPTIONS and DELETE
requests like for GET, and a request body for PUT requests like for POST. This
encoding was arbitrary and inconsistent with Django's behavior when it
receives the requests, so it was removed in Django 1.5.
If you were using the ``data`` parameter in an OPTIONS or a DELETE request,
you must convert it to a query string and append it to the ``path`` parameter.
If you were using the ``data`` parameter in a PUT request without a
``content_type``, you must encode your data before passing it to the test
client and set the ``content_type`` argument.
System version of :mod:`simplejson` no longer used
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As explained below, Django 1.5 deprecates
``django.utils.simplejson`` in favor of Python 2.6's built-in :mod:`json`
module. In theory, this change is harmless. Unfortunately, because of
incompatibilities between versions of :mod:`simplejson`, it may trigger errors
in some circumstances.
JSON-related features in Django 1.4 always used ``django.utils.simplejson``.
This module was actually:
- A system version of :mod:`simplejson`, if one was available (ie. ``import
simplejson`` works), if it was more recent than Django's built-in copy or it
had the C speedups, or
- The :mod:`json` module from the standard library, if it was available (ie.
Python 2.6 or greater), or
- A built-in copy of version 2.0.7 of :mod:`simplejson`.
In Django 1.5, those features use Python's :mod:`json` module, which is based
on version 2.0.9 of :mod:`simplejson`.
There are no known incompatibilities between Django's copy of version 2.0.7 and
Python's copy of version 2.0.9. However, there are some incompatibilities
between other versions of :mod:`simplejson`:
- While the :mod:`simplejson` API is documented as always returning unicode
strings, the optional C implementation can return a byte string. This was
fixed in Python 2.7.
- :class:`simplejson.JSONEncoder` gained a ``namedtuple_as_object`` keyword
argument in version 2.2.
More information on these incompatibilities is available in `ticket #18023`_.
The net result is that, if you have installed :mod:`simplejson` and your code
uses Django's serialization internals directly -- for instance
``django.core.serializers.json.DjangoJSONEncoder``, the switch from
:mod:`simplejson` to :mod:`json` could break your code. (In general, changes to
internals aren't documented; we're making an exception here.)
At this point, the maintainers of Django believe that using :mod:`json` from
the standard library offers the strongest guarantee of backwards-compatibility.
They recommend to use it from now on.
.. _ticket #18023: https://code.djangoproject.com/ticket/18023#comment:10
String types of hasher method parameters
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you have written a :ref:`custom password hasher <auth_password_storage>`,
your ``encode()``, ``verify()`` or ``safe_summary()`` methods should accept
Unicode parameters (``password``, ``salt`` or ``encoded``). If any of the
hashing methods need byte strings, you can use the
:func:`~django.utils.encoding.force_bytes` utility to encode the strings.
Validation of previous_page_number and next_page_number
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When using :doc:`object pagination </topics/pagination>`,
the ``previous_page_number()`` and ``next_page_number()`` methods of the
:class:`~django.core.paginator.Page` object did not check if the returned
number was inside the existing page range.
It does check it now and raises an :exc:`~django.core.paginator.InvalidPage`
exception when the number is either too low or too high.
Behavior of autocommit database option on PostgreSQL changed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PostgreSQL's autocommit option didn't work as advertised previously. It did
work for single transaction block, but after the first block was left the
autocommit behavior was never restored. This bug is now fixed in 1.5. While
this is only a bug fix, it is worth checking your applications behavior if
you are using PostgreSQL together with the autocommit option.
Session not saved on 500 responses
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django's session middleware will skip saving the session data if the
response's status code is 500.
Email checks on failed admin login
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Prior to Django 1.5, if you attempted to log into the admin interface and
mistakenly used your email address instead of your username, the admin
interface would provide a warning advising that your email address was
not your username. In Django 1.5, the introduction of
:ref:`custom User models <auth-custom-user>` has required the removal of this
warning. This doesn't change the login behavior of the admin site; it only
affects the warning message that is displayed under one particular mode of
login failure.
Changes in tests execution
~~~~~~~~~~~~~~~~~~~~~~~~~~
Some changes have been introduced in the execution of tests that might be
backward-incompatible for some testing setups:
Database flushing in ``django.test.TransactionTestCase``
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Previously, the test database was truncated *before* each test run in a
:class:`~django.test.TransactionTestCase`.
In order to be able to run unit tests in any order and to make sure they are
always isolated from each other, :class:`~django.test.TransactionTestCase` will
now reset the database *after* each test run instead.
No more implicit DB sequences reset
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
:class:`~django.test.TransactionTestCase` tests used to reset primary key
sequences automatically together with the database flushing actions described
above.
This has been changed so no sequences are implicitly reset. This can cause
:class:`~django.test.TransactionTestCase` tests that depend on hard-coded
primary key values to break.
The new :attr:`~django.test.TransactionTestCase.reset_sequences` attribute can
be used to force the old behavior for :class:`~django.test.TransactionTestCase`
that might need it.
Ordering of tests
^^^^^^^^^^^^^^^^^
In order to make sure all ``TestCase`` code starts with a clean database,
tests are now executed in the following order:
* First, all unittests (including :class:`unittest.TestCase`,
:class:`~django.test.SimpleTestCase`, :class:`~django.test.TestCase` and
:class:`~django.test.TransactionTestCase`) are run with no particular ordering
guaranteed nor enforced among them.
* Then any other tests (e.g. doctests) that may alter the database without
restoring it to its original state are run.
This should not cause any problems unless you have existing doctests which
assume a :class:`~django.test.TransactionTestCase` executed earlier left some
database state behind or unit tests that rely on some form of state being
preserved after the execution of other tests. Such tests are already very
fragile, and must now be changed to be able to run independently.
`cleaned_data` dictionary kept for invalid forms
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The :attr:`~django.forms.Form.cleaned_data` dictionary is now always present
after form validation. When the form doesn't validate, it contains only the
fields that passed validation. You should test the success of the validation
with the :meth:`~django.forms.Form.is_valid()` method and not with the
presence or absence of the :attr:`~django.forms.Form.cleaned_data` attribute
on the form.
Miscellaneous
~~~~~~~~~~~~~
* :class:`django.forms.ModelMultipleChoiceField` now returns an empty
``QuerySet`` as the empty value instead of an empty list.
* :func:`~django.utils.http.int_to_base36` properly raises a
:exc:`TypeError` instead of :exc:`ValueError` for non-integer inputs.
* The ``slugify`` template filter is now available as a standard python
function at :func:`django.utils.text.slugify`. Similarly, ``remove_tags`` is
available at :func:`django.utils.html.remove_tags`.
* Uploaded files are no longer created as executable by default. If you need
them to be executable change :setting:`FILE_UPLOAD_PERMISSIONS` to your
needs. The new default value is ``0o666`` (octal) and the current umask value
is first masked out.
* The :class:`F expressions <django.db.models.F>` supported bitwise operators
by ``&`` and ``|``. These operators are now available using ``.bitand()`` and
``.bitor()`` instead. The removal of ``&`` and ``|`` was done to be
consistent with :ref:`Q() expressions <complex-lookups-with-q>` and
``QuerySet`` combining where the operators are used as boolean AND and OR
operators.
* The :ttag:`csrf_token` template tag is no longer enclosed in a div. If you need
HTML validation against pre-HTML5 Strict DTDs, you should add a div around it
in your pages.
Features deprecated in 1.5
==========================
``AUTH_PROFILE_MODULE`` setting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With the introduction of :ref:`custom User models <auth-custom-user>`, there is
no longer any need for a built-in mechanism to store user profile data.
You can still define user profiles models that have a one-to-one relation with
the User model - in fact, for many applications needing to associate data with
a User account, this will be an appropriate design pattern to follow. However,
the ``AUTH_PROFILE_MODULE`` setting, and the
``django.contrib.auth.models.User.get_profile()`` method for accessing
the user profile model, should not be used any longer.
Streaming behavior of :class:`~django.http.HttpResponse`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django 1.5 deprecates the ability to stream a response by passing an iterator
to :class:`~django.http.HttpResponse`. If you rely on this behavior, switch to
:class:`~django.http.StreamingHttpResponse`. See above for more details.
In Django 1.7 and above, the iterator will be consumed immediately by
:class:`~django.http.HttpResponse`.
``django.utils.simplejson``
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Since Django 1.5 drops support for Python 2.5, we can now rely on the
:mod:`json` module being available in Python's standard library, so we've
removed our own copy of :mod:`simplejson`. You should now import :mod:`json`
instead of ``django.utils.simplejson``.
Unfortunately, this change might have unwanted side-effects, because of
incompatibilities between versions of :mod:`simplejson` -- see the backwards-
incompatible changes section. If you rely on features added to :mod:`simplejson`
after it became Python's :mod:`json`, you should import :mod:`simplejson`
explicitly.
``django.utils.encoding.StrAndUnicode``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``django.utils.encoding.StrAndUnicode`` mix-in has been deprecated.
Define a ``__str__`` method and apply the
:func:`~django.utils.encoding.python_2_unicode_compatible` decorator instead.
``django.utils.itercompat.product``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``django.utils.itercompat.product`` function has been deprecated. Use
the built-in :func:`itertools.product` instead.
``django.utils.markup``
~~~~~~~~~~~~~~~~~~~~~~~
The markup contrib module has been deprecated and will follow an accelerated
deprecation schedule. Direct use of python markup libraries or 3rd party tag
libraries is preferred to Django maintaining this functionality in the
framework.

706
docs/releases/1.5-beta-1.txt
View File

@ -1,706 +0,0 @@
=============================
Django 1.5 beta release notes
=============================
November 27, 2012.
Welcome to Django 1.5 beta!
This is the second in a series of preview/development releases leading
up to the eventual release of Django 1.5, scheduled for December
2012. This release is primarily targeted at developers who are
interested in trying out new features and testing the Django codebase
to help identify and resolve bugs prior to the final 1.5 release.
As such, this release is *not* intended for production use, and any such use
is discouraged.
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.4 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.5`_
.. _`backwards incompatible changes`: `Backwards incompatible changes in 1.5`_
.. _`begun the deprecation process for some features`: `Features deprecated in 1.5`_
Overview
========
The biggest new feature in Django 1.5 is the `configurable User model`_. Before
Django 1.5, applications that wanted to use Django's auth framework
(:mod:`django.contrib.auth`) were forced to use Django's definition of a "user".
In Django 1.5, you can now swap out the ``User`` model for one that you write
yourself. This could be a simple extension to the existing ``User`` model -- for
example, you could add a Twitter or Facebook ID field -- or you could completely
replace the ``User`` with one totally customized for your site.
Django 1.5 is also the first release with `Python 3 support`_! We're labeling
this support "experimental" because we don't yet consider it production-ready,
but everything's in place for you to start porting your apps to Python 3.
Our next release, Django 1.6, will support Python 3 without reservations.
Other notable new features in Django 1.5 include:
* `Support for saving a subset of model's fields`_ -
:meth:`Model.save() <django.db.models.Model.save()>` now accepts an
``update_fields`` argument, letting you specify which fields are
written back to the database when you call ``save()``. This can help
in high-concurrency operations, and can improve performance.
* Better `support for streaming responses <#explicit-streaming-responses-beta-1>`_ via
the new :class:`~django.http.StreamingHttpResponse` response class.
* `GeoDjango`_ now supports PostGIS 2.0.
* ... and more; `see below <#what-s-new-in-django-1-5>`_.
Wherever possible we try to introduce new features in a backwards-compatible
manner per :doc:`our API stability policy </misc/api-stability>`.
However, as with previous releases, Django 1.5 ships with some minor
`backwards incompatible changes`_; people upgrading from previous versions
of Django should read that list carefully.
One deprecated feature worth noting is the shift to "new-style" :ttag:`url` tag.
Prior to Django 1.3, syntax like ``{% url myview %}`` was interpreted
incorrectly (Django considered ``"myview"`` to be a literal name of a view, not
a template variable named ``myview``). Django 1.3 and above introduced the
``{% load url from future %}`` syntax to bring in the corrected behavior where
``myview`` was seen as a variable.
The upshot of this is that if you are not using ``{% load url from future %}``
in your templates, you'll need to change tags like ``{% url myview %}`` to
``{% url "myview" %}``. If you *were* using ``{% load url from future %}`` you
can simply remove that line under Django 1.5
Python compatibility
====================
Django 1.5 requires Python 2.6.5 or above, though we **highly recommend**
Python 2.7.3 or above. Support for Python 2.5 and below has been dropped.
This change should affect only a small number of Django users, as most
operating-system vendors today are shipping Python 2.6 or newer as their default
version. If you're still using Python 2.5, however, you'll need to stick to
Django 1.4 until you can upgrade your Python version. Per :doc:`our support
policy </internals/release-process>`, Django 1.4 will continue to receive
security support until the release of Django 1.6.
Django 1.5 does not run on a Jython final release, because Jython's latest
release doesn't currently support Python 2.6. However, Jython currently does
offer an alpha release featuring 2.7 support, and Django 1.5 supports that alpha
release.
Python 3 support
~~~~~~~~~~~~~~~~
Django 1.5 introduces support for Python 3 - specifically, Python
3.2 and above. This comes in the form of a **single** codebase; you don't
need to install a different version of Django on Python 3. This means that
you can write applications targeted for just Python 2, just Python 3, or single
applications that support both platforms.
However, we're labeling this support "experimental" for now: although it's
received extensive testing via our automated test suite, it's received very
little real-world testing. We've done our best to eliminate bugs, but we can't
be sure we covered all possible uses of Django. Further, Django's more than a
web framework; it's an ecosystem of pluggable components. At this point, very
few third-party applications have been ported to Python 3, so it's unlikely
that a real-world application will have all its dependencies satisfied under
Python 3.
Thus, we're recommending that Django 1.5 not be used in production under Python
3. Instead, use this opportunity to begin :doc:`porting applications to Python 3
</topics/python3>`. If you're an author of a pluggable component, we encourage you
to start porting now.
We plan to offer first-class, production-ready support for Python 3 in our next
release, Django 1.6.
What's new in Django 1.5
========================
Configurable User model
~~~~~~~~~~~~~~~~~~~~~~~
In Django 1.5, you can now use your own model as the store for user-related
data. If your project needs a username with more than 30 characters, or if
you want to store user's names in a format other than first name/last name,
or you want to put custom profile information onto your User object, you can
now do so.
If you have a third-party reusable application that references the User model,
you may need to make some changes to the way you reference User instances. You
should also document any specific features of the User model that your
application relies upon.
See the :ref:`documentation on custom User models <auth-custom-user>` for
more details.
Support for saving a subset of model's fields
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The method :meth:`Model.save() <django.db.models.Model.save()>` has a new
keyword argument ``update_fields``. By using this argument it is possible to
save only a select list of model's fields. This can be useful for performance
reasons or when trying to avoid overwriting concurrent changes.
Deferred instances (those loaded by .only() or .defer()) will automatically
save just the loaded fields. If any field is set manually after load, that
field will also get updated on save.
See the :meth:`Model.save() <django.db.models.Model.save()>` documentation for
more details.
Caching of related model instances
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When traversing relations, the ORM will avoid re-fetching objects that were
previously loaded. For example, with the tutorial's models::
>>> first_poll = Poll.objects.all()[0]
>>> first_choice = first_poll.choice_set.all()[0]
>>> first_choice.poll is first_poll
True
In Django 1.5, the third line no longer triggers a new SQL query to fetch
``first_choice.poll``; it was set by the second line.
For one-to-one relationships, both sides can be cached. For many-to-one
relationships, only the single side of the relationship can be cached. This
is particularly helpful in combination with ``prefetch_related``.
.. _explicit-streaming-responses-beta-1:
Explicit support for streaming responses
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Before Django 1.5, it was possible to create a streaming response by passing
an iterator to :class:`~django.http.HttpResponse`. But this was unreliable:
any middleware that accessed the :attr:`~django.http.HttpResponse.content`
attribute would consume the iterator prematurely.
You can now explicitly generate a streaming response with the new
:class:`~django.http.StreamingHttpResponse` class. This class exposes a
:class:`~django.http.StreamingHttpResponse.streaming_content` attribute which
is an iterator.
Since :class:`~django.http.StreamingHttpResponse` does not have a ``content``
attribute, middleware that needs access to the response content must test for
streaming responses and behave accordingly. See :ref:`response-middleware` for
more information.
``{% verbatim %}`` template tag
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To make it easier to deal with javascript templates which collide with Django's
syntax, you can now use the :ttag:`verbatim` block tag to avoid parsing the
tag's content.
Retrieval of ``ContentType`` instances associated with proxy models
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The methods :meth:`ContentTypeManager.get_for_model() <django.contrib.contenttypes.models.ContentTypeManager.get_for_model()>`
and :meth:`ContentTypeManager.get_for_models() <django.contrib.contenttypes.models.ContentTypeManager.get_for_models()>`
have a new keyword argument – respectively ``for_concrete_model`` and ``for_concrete_models``.
By passing ``False`` using this argument it is now possible to retrieve the
:class:`ContentType <django.contrib.contenttypes.models.ContentType>`
associated with proxy models.
New ``view`` variable in class-based views context
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In all :doc:`generic class-based views </topics/class-based-views/index>`
(or any class-based view inheriting from ``ContextMixin``), the context dictionary
contains a ``view`` variable that points to the ``View`` instance.
GeoDjango
~~~~~~~~~
* :class:`~django.contrib.gis.geos.LineString` and
:class:`~django.contrib.gis.geos.MultiLineString` GEOS objects now support the
:meth:`~django.contrib.gis.geos.GEOSGeometry.interpolate()` and
:meth:`~django.contrib.gis.geos.GEOSGeometry.project()` methods
(so-called linear referencing).
* The ``wkb`` and ``hex`` properties of
:class:`~django.contrib.gis.geos.GEOSGeometry` objects preserve the Z
dimension.
* Support for PostGIS 2.0 has been added and support for GDAL < 1.5 has been
dropped.
Minor features
~~~~~~~~~~~~~~
Django 1.5 also includes several smaller improvements worth noting:
* The template engine now interprets ``True``, ``False`` and ``None`` as the
corresponding Python objects.
* :mod:`django.utils.timezone` provides a helper for converting aware
datetimes between time zones. See :func:`~django.utils.timezone.localtime`.
* The generic views support OPTIONS requests.
* Management commands do not raise ``SystemExit`` any more when called by code
from :ref:`call_command <call-command>`. Any exception raised by the command
(mostly :ref:`CommandError <ref-command-exceptions>`) is propagated.
* The dumpdata management command outputs one row at a time, preventing
out-of-memory errors when dumping large datasets.
* In the localflavor for Canada, "pq" was added to the acceptable codes for
Quebec. It's an old abbreviation.
* The :ref:`receiver <connecting-receiver-functions>` decorator is now able to
connect to more than one signal by supplying a list of signals.
* In the admin, you can now filter users by groups which they are members of.
* :meth:`QuerySet.bulk_create()
<django.db.models.query.QuerySet.bulk_create>` now has a batch_size
argument. By default the batch_size is unlimited except for SQLite where
single batch is limited so that 999 parameters per query isn't exceeded.
* The :setting:`LOGIN_URL` and :setting:`LOGIN_REDIRECT_URL` settings now also
accept view function names and
:ref:`named URL patterns <naming-url-patterns>`. This allows you to reduce
configuration duplication. More information can be found in the
:func:`~django.contrib.auth.decorators.login_required` documentation.
* Django now provides a mod_wsgi :doc:`auth handler
</howto/deployment/wsgi/apache-auth>`.
* The :meth:`QuerySet.delete() <django.db.models.query.QuerySet.delete>`
and :meth:`Model.delete() <django.db.models.Model.delete()>` can now take
fast-path in some cases. The fast-path allows for less queries and less
objects fetched into memory. See :meth:`QuerySet.delete()
<django.db.models.query.QuerySet.delete>` for details.
* An instance of :class:`~django.core.urlresolvers.ResolverMatch` is stored on
the request as ``resolver_match``.
* By default, all logging messages reaching the ``django`` logger when
:setting:`DEBUG` is ``True`` are sent to the console (unless you redefine the
logger in your :setting:`LOGGING` setting).
* When using :class:`~django.template.RequestContext`, it is now possible to
look up permissions by using ``{% if 'someapp.someperm' in perms %}``
in templates.
* It's not required any more to have ``404.html`` and ``500.html`` templates in
the root templates directory. Django will output some basic error messages for
both situations when those templates are not found. Of course, it's still
recommended as good practice to provide those templates in order to present
pretty error pages to the user.
* :mod:`django.contrib.auth` provides a new signal that is emitted
whenever a user fails to login successfully. See
:data:`~django.contrib.auth.signals.user_login_failed`
* The loaddata management command now supports an
:djadminopt:`--ignorenonexistent` option to ignore data for fields that no
longer exist.
* :meth:`~django.test.SimpleTestCase.assertXMLEqual` and
:meth:`~django.test.SimpleTestCase.assertXMLNotEqual` new assertions allow
you to test equality for XML content at a semantic level, without caring for
syntax differences (spaces, attribute order, etc.).
* RemoteUserMiddleware now forces logout when the REMOTE_USER header
disappears during the same browser session.
* The :ref:`cache-based session backend <cached-sessions-backend>` can store
session data in a non-default cache.
* Multi-column indexes can now be created on models. Read the
:attr:`~django.db.models.Options.index_together` documentation for more
information.
* During Django's logging configuration verbose Deprecation warnings are
enabled and warnings are captured into the logging system. Logged warnings
are routed through the ``console`` logging handler, which by default requires
:setting:`DEBUG` to be True for output to be generated. The result is that
DeprecationWarnings should be printed to the console in development
environments the way they have been in Python versions < 2.7.
* The API for :meth:`django.contrib.admin.ModelAdmin.message_user` method has
been modified to accept additional arguments adding capabilities similar to
:func:`django.contrib.messages.add_message`. This is useful for generating
error messages from admin actions.
* The admin's list filters can now be customized per-request thanks to the new
:meth:`django.contrib.admin.ModelAdmin.get_list_filter` method.
Backwards incompatible changes in 1.5
=====================================
.. 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.
Context in year archive class-based views
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For consistency with the other date-based generic views,
:class:`~django.views.generic.dates.YearArchiveView` now passes ``year`` in
the context as a :class:`datetime.date` rather than a string. If you are
using ``{{ year }}`` in your templates, you must replace it with ``{{
year|date:"Y" }}``.
``next_year`` and ``previous_year`` were also added in the context. They are
calculated according to ``allow_empty`` and ``allow_future``.
Context in year and month archive class-based views
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:class:`~django.views.generic.dates.YearArchiveView` and
:class:`~django.views.generic.dates.MonthArchiveView` were documented to
provide a ``date_list`` sorted in ascending order in the context, like their
function-based predecessors, but it actually was in descending order. In 1.5,
the documented order was restored. You may want to add (or remove) the
``reversed`` keyword when you're iterating on ``date_list`` in a template::
{% for date in date_list reversed %}
:class:`~django.views.generic.dates.ArchiveIndexView` still provides a
``date_list`` in descending order.
Context in TemplateView
~~~~~~~~~~~~~~~~~~~~~~~
For consistency with the design of the other generic views,
:class:`~django.views.generic.base.TemplateView` no longer passes a ``params``
dictionary into the context, instead passing the variables from the URLconf
directly into the context.
Non-form data in HTTP requests
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:attr:`request.POST <django.http.HttpRequest.POST>` will no longer include data
posted via HTTP requests with non form-specific content-types in the header.
In prior versions, data posted with content-types other than
``multipart/form-data`` or ``application/x-www-form-urlencoded`` would still
end up represented in the :attr:`request.POST <django.http.HttpRequest.POST>`
attribute. Developers wishing to access the raw POST data for these cases,
should use the :attr:`request.body <django.http.HttpRequest.body>` attribute
instead.
OPTIONS, PUT and DELETE requests in the test client
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Unlike GET and POST, these HTTP methods aren't implemented by web browsers.
Rather, they're used in APIs, which transfer data in various formats such as
JSON or XML. Since such requests may contain arbitrary data, Django doesn't
attempt to decode their body.
However, the test client used to build a query string for OPTIONS and DELETE
requests like for GET, and a request body for PUT requests like for POST. This
encoding was arbitrary and inconsistent with Django's behavior when it
receives the requests, so it was removed in Django 1.5.
If you were using the ``data`` parameter in an OPTIONS or a DELETE request,
you must convert it to a query string and append it to the ``path`` parameter.
If you were using the ``data`` parameter in a PUT request without a
``content_type``, you must encode your data before passing it to the test
client and set the ``content_type`` argument.
.. _simplejson-incompatibilities-beta-1:
System version of :mod:`simplejson` no longer used
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:ref:`As explained below <simplejson-deprecation-beta-1>`, Django 1.5 deprecates
``django.utils.simplejson`` in favor of Python 2.6's built-in :mod:`json`
module. In theory, this change is harmless. Unfortunately, because of
incompatibilities between versions of :mod:`simplejson`, it may trigger errors
in some circumstances.
JSON-related features in Django 1.4 always used ``django.utils.simplejson``.
This module was actually:
- A system version of :mod:`simplejson`, if one was available (ie. ``import
simplejson`` works), if it was more recent than Django's built-in copy or it
had the C speedups, or
- The :mod:`json` module from the standard library, if it was available (ie.
Python 2.6 or greater), or
- A built-in copy of version 2.0.7 of :mod:`simplejson`.
In Django 1.5, those features use Python's :mod:`json` module, which is based
on version 2.0.9 of :mod:`simplejson`.
There are no known incompatibilities between Django's copy of version 2.0.7 and
Python's copy of version 2.0.9. However, there are some incompatibilities
between other versions of :mod:`simplejson`:
- While the :mod:`simplejson` API is documented as always returning unicode
strings, the optional C implementation can return a byte string. This was
fixed in Python 2.7.
- :class:`simplejson.JSONEncoder` gained a ``namedtuple_as_object`` keyword
argument in version 2.2.
More information on these incompatibilities is available in `ticket #18023`_.
The net result is that, if you have installed :mod:`simplejson` and your code
uses Django's serialization internals directly -- for instance
``django.core.serializers.json.DjangoJSONEncoder``, the switch from
:mod:`simplejson` to :mod:`json` could break your code. (In general, changes to
internals aren't documented; we're making an exception here.)
At this point, the maintainers of Django believe that using :mod:`json` from
the standard library offers the strongest guarantee of backwards-compatibility.
They recommend to use it from now on.
.. _ticket #18023: https://code.djangoproject.com/ticket/18023#comment:10
String types of hasher method parameters
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you have written a :ref:`custom password hasher <auth_password_storage>`,
your ``encode()``, ``verify()`` or ``safe_summary()`` methods should accept
Unicode parameters (``password``, ``salt`` or ``encoded``). If any of the
hashing methods need byte strings, you can use the
:func:`~django.utils.encoding.force_bytes` utility to encode the strings.
Validation of previous_page_number and next_page_number
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When using :doc:`object pagination </topics/pagination>`,
the ``previous_page_number()`` and ``next_page_number()`` methods of the
:class:`~django.core.paginator.Page` object did not check if the returned
number was inside the existing page range.
It does check it now and raises an :exc:`~django.core.paginator.InvalidPage`
exception when the number is either too low or too high.
Behavior of autocommit database option on PostgreSQL changed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PostgreSQL's autocommit option didn't work as advertised previously. It did
work for single transaction block, but after the first block was left the
autocommit behavior was never restored. This bug is now fixed in 1.5. While
this is only a bug fix, it is worth checking your applications behavior if
you are using PostgreSQL together with the autocommit option.
Session not saved on 500 responses
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django's session middleware will skip saving the session data if the
response's status code is 500.
Email checks on failed admin login
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Prior to Django 1.5, if you attempted to log into the admin interface and
mistakenly used your email address instead of your username, the admin
interface would provide a warning advising that your email address was
not your username. In Django 1.5, the introduction of
:ref:`custom User models <auth-custom-user>` has required the removal of this
warning. This doesn't change the login behavior of the admin site; it only
affects the warning message that is displayed under one particular mode of
login failure.
Changes in tests execution
~~~~~~~~~~~~~~~~~~~~~~~~~~
Some changes have been introduced in the execution of tests that might be
backward-incompatible for some testing setups:
Database flushing in ``django.test.TransactionTestCase``
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Previously, the test database was truncated *before* each test run in a
:class:`~django.test.TransactionTestCase`.
In order to be able to run unit tests in any order and to make sure they are
always isolated from each other, :class:`~django.test.TransactionTestCase` will
now reset the database *after* each test run instead.
No more implicit DB sequences reset
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
:class:`~django.test.TransactionTestCase` tests used to reset primary key
sequences automatically together with the database flushing actions described
above.
This has been changed so no sequences are implicitly reset. This can cause
:class:`~django.test.TransactionTestCase` tests that depend on hard-coded
primary key values to break.
The new :attr:`~django.test.TransactionTestCase.reset_sequences` attribute can
be used to force the old behavior for :class:`~django.test.TransactionTestCase`
that might need it.
Ordering of tests
^^^^^^^^^^^^^^^^^
In order to make sure all ``TestCase`` code starts with a clean database,
tests are now executed in the following order:
* First, all unittests (including :class:`unittest.TestCase`,
:class:`~django.test.SimpleTestCase`, :class:`~django.test.TestCase` and
:class:`~django.test.TransactionTestCase`) are run with no particular ordering
guaranteed nor enforced among them.
* Then any other tests (e.g. doctests) that may alter the database without
restoring it to its original state are run.
This should not cause any problems unless you have existing doctests which
assume a :class:`~django.test.TransactionTestCase` executed earlier left some
database state behind or unit tests that rely on some form of state being
preserved after the execution of other tests. Such tests are already very
fragile, and must now be changed to be able to run independently.
`cleaned_data` dictionary kept for invalid forms
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The :attr:`~django.forms.Form.cleaned_data` dictionary is now always present
after form validation. When the form doesn't validate, it contains only the
fields that passed validation. You should test the success of the validation
with the :meth:`~django.forms.Form.is_valid()` method and not with the
presence or absence of the :attr:`~django.forms.Form.cleaned_data` attribute
on the form.
Behavior of :djadmin:`syncdb` with multiple databases
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:djadmin:`syncdb` now queries the database routers to determine if content
types (when :mod:`~django.contrib.contenttypes` is enabled) and permissions
(when :mod:`~django.contrib.auth` is enabled) should be created in the target
database. Previously, it created them in the default database, even when
another database was specified with the :djadminopt:`--database` option.
If you use :djadmin:`syncdb` on multiple databases, you should ensure that
your routers allow synchronizing content types and permissions to only one of
them. See the docs on the :ref:`behavior of contrib apps with multiple
databases <contrib_app_multiple_databases>` for more information.
Miscellaneous
~~~~~~~~~~~~~
* :class:`django.forms.ModelMultipleChoiceField` now returns an empty
``QuerySet`` as the empty value instead of an empty list.
* :func:`~django.utils.http.int_to_base36` properly raises a
:exc:`TypeError` instead of :exc:`ValueError` for non-integer inputs.
* The ``slugify`` template filter is now available as a standard python
function at :func:`django.utils.text.slugify`. Similarly, ``remove_tags`` is
available at :func:`django.utils.html.remove_tags`.
* Uploaded files are no longer created as executable by default. If you need
them to be executable change :setting:`FILE_UPLOAD_PERMISSIONS` to your
needs. The new default value is ``0o666`` (octal) and the current umask value
is first masked out.
* The :class:`F expressions <django.db.models.F>` supported bitwise operators by
``&`` and ``|``. These operators are now available using ``.bitand()`` and
``.bitor()`` instead. The removal of ``&`` and ``|`` was done to be
consistent with :ref:`Q() expressions <complex-lookups-with-q>` and
``QuerySet`` combining where the operators are used as boolean AND and OR
operators.
* In a ``filter()`` call, when :class:`F expressions <django.db.models.F>`
contained lookups spanning multi-valued relations, they didn't always reuse
the same relations as other lookups along the same chain. This was changed,
and now F() expressions will always use the same relations as other lookups
within the same ``filter()`` call.
* The :ttag:`csrf_token` template tag is no longer enclosed in a div. If you need
HTML validation against pre-HTML5 Strict DTDs, you should add a div around it
in your pages.
* The template tags library ``adminmedia``, which only contained the
deprecated template tag ``{% admin_media_prefix %}``, was removed.
Attempting to load it with ``{% load adminmedia %}`` will fail. If your
templates still contain that line you must remove it.
Features deprecated in 1.5
==========================
.. _simplejson-deprecation-beta-1:
``AUTH_PROFILE_MODULE``
~~~~~~~~~~~~~~~~~~~~~~~
With the introduction of :ref:`custom User models <auth-custom-user>`, there is
no longer any need for a built-in mechanism to store user profile data.
You can still define user profiles models that have a one-to-one relation with
the User model - in fact, for many applications needing to associate data with
a User account, this will be an appropriate design pattern to follow. However,
the ``AUTH_PROFILE_MODULE`` setting, and the
``django.contrib.auth.models.User.get_profile()`` method for accessing
the user profile model, should not be used any longer.
Streaming behavior of :class:`~django.http.HttpResponse`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django 1.5 deprecates the ability to stream a response by passing an iterator
to :class:`~django.http.HttpResponse`. If you rely on this behavior, switch to
:class:`~django.http.StreamingHttpResponse`. See
:ref:`explicit-streaming-responses-beta-1` above.
In Django 1.7 and above, the iterator will be consumed immediately by
:class:`~django.http.HttpResponse`.
``django.utils.simplejson``
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Since Django 1.5 drops support for Python 2.5, we can now rely on the
:mod:`json` module being available in Python's standard library, so we've
removed our own copy of :mod:`simplejson`. You should now import :mod:`json`
instead of ``django.utils.simplejson``.
Unfortunately, this change might have unwanted side-effects, because of
incompatibilities between versions of :mod:`simplejson` -- see the
:ref:`backwards-incompatible changes <simplejson-incompatibilities-beta-1>` section.
If you rely on features added to :mod:`simplejson` after it became Python's
:mod:`json`, you should import :mod:`simplejson` explicitly.
``django.utils.encoding.StrAndUnicode``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``django.utils.encoding.StrAndUnicode`` mix-in has been deprecated.
Define a ``__str__`` method and apply the
:func:`~django.utils.encoding.python_2_unicode_compatible` decorator instead.
``django.utils.itercompat.product``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``django.utils.itercompat.product`` function has been deprecated. Use
the built-in :func:`itertools.product` instead.
``django.utils.markup``
~~~~~~~~~~~~~~~~~~~~~~~
The markup contrib module has been deprecated and will follow an accelerated
deprecation schedule. Direct use of python markup libraries or 3rd party tag
libraries is preferred to Django maintaining this functionality in the
framework.
``cleanup`` management command
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``cleanup`` management command has been deprecated and replaced by
:djadmin:`clearsessions`.
``daily_cleanup.py`` script
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The undocumented ``daily_cleanup.py`` script has been deprecated. Use the
:djadmin:`clearsessions` management command instead.
``depth`` keyword argument in ``select_related``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``depth`` keyword argument in
:meth:`~django.db.models.query.QuerySet.select_related` has been deprecated.
You should use field names instead.

25
docs/releases/index.txt
View File

@ -150,30 +150,7 @@ added to all affected release series.
Additionally, :doc:`an archive of disclosed security issues
</releases/security>` is maintained.
Development releases
====================
These notes are retained for historical purposes. If you are upgrading
between formal Django releases, you don't need to worry about these
notes.
.. toctree::
:maxdepth: 1
:hidden:
security
1.5-beta-1
1.5-alpha-1
1.4-beta-1
1.4-alpha-1
1.3-beta-1
1.3-alpha-1
1.2-rc-1
1.2-beta-1
1.2-alpha-1
1.1-rc-1
1.1-beta-1
1.1-alpha-1
1.0-beta-2
1.0-beta
1.0-alpha-2
1.0-alpha-1