mirror of https://github.com/django/django.git
Cleaned up the release notes index page, and added some stub 1.1.2 and 1.2 release notes.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11760 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Russell Keith-Magee
parent
f5fefcc8c9
commit
cf169d9e12
|
|
@ -201,5 +201,5 @@ The Django open-source project
|
|||
|
||||
* **Django over time:**
|
||||
:ref:`API stability <misc-api-stability>` |
|
||||
:ref:`Release notes <releases-index>` |
|
||||
:ref:`Release notes and upgrading instructions <releases-index>` |
|
||||
:ref:`Deprecation Timeline <internals-deprecation>`
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ To enable CSRF protection for your views, follow these steps:
|
|||
``django.views.decorators.csrf.csrf_protect`` on particular views you
|
||||
want to protect (see below).
|
||||
|
||||
2. In any template that uses a POST form, use the ``csrf_token`` tag inside
|
||||
2. In any template that uses a POST form, use the :ttag:`csrf_token` tag inside
|
||||
the ``<form>`` element if the form is for an internal URL, e.g.::
|
||||
|
||||
<form action="" method="POST">{% csrf_token %}
|
||||
|
|
@ -130,7 +130,7 @@ as ``CsrfResponseMiddleware``, and it can be used by following these steps:
|
|||
Use of the ``CsrfResponseMiddleware`` is not recommended because of the
|
||||
performance hit it imposes, and because of a potential security problem (see
|
||||
below). It can be used as an interim measure until applications have been
|
||||
updated to use the ``{% csrf_token %}`` tag. It is deprecated and will be
|
||||
updated to use the :ttag:`csrf_token` tag. It is deprecated and will be
|
||||
removed in Django 1.4.
|
||||
|
||||
Django 1.1 and earlier provided a single ``CsrfMiddleware`` class. This is also
|
||||
|
|
@ -199,7 +199,7 @@ Note that contrib apps, such as the admin, have been updated to use the
|
|||
``CsrfViewMiddleware`` to your settings. However, if you have supplied
|
||||
customised templates to any of the view functions of contrib apps (whether
|
||||
explicitly via a keyword argument, or by overriding built-in templates), **you
|
||||
MUST update them** to include the ``csrf_token`` template tag as described
|
||||
MUST update them** to include the :ttag:`csrf_token` template tag as described
|
||||
above, or they will stop working. (If you cannot update these templates for
|
||||
some reason, you will be forced to use ``CsrfResponseMiddleware`` for these
|
||||
views to continue working).
|
||||
|
|
@ -364,7 +364,7 @@ exactly that.
|
|||
Caching
|
||||
=======
|
||||
|
||||
If the ``csrf_token`` template tag is used by a template (or the ``get_token``
|
||||
If the :ttag:`csrf_token` template tag is used by a template (or the ``get_token``
|
||||
function is called some other way), ``CsrfViewMiddleware`` will add a cookie and
|
||||
a ``Vary: Cookie`` header to the response. Similarly,
|
||||
``CsrfResponseMiddleware`` will send the ``Vary: Cookie`` header if it inserted
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ comment
|
|||
|
||||
Ignore everything between ``{% comment %}`` and ``{% endcomment %}``
|
||||
|
||||
.. templatetag:: cycle
|
||||
.. templatetag:: csrf_token
|
||||
|
||||
csrf_token
|
||||
~~~~~~~~~~
|
||||
|
|
@ -63,6 +63,8 @@ future compatibility purposes. In Django 1.2 and later, it is used for CSRF
|
|||
protection, as described in the documentation for :ref:`Cross Site Request
|
||||
Forgeries <ref-contrib-csrf>`.
|
||||
|
||||
.. templatetag:: cycle
|
||||
|
||||
cycle
|
||||
~~~~~
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,36 @@
|
|||
.. _releases-1.1.2:
|
||||
|
||||
==============================================
|
||||
Django 1.1.2 release notes — UNDER DEVELOPMENT
|
||||
==============================================
|
||||
|
||||
This page documents release notes for the as-yet-unreleased Django
|
||||
1.1.2. As such it is tentative and subject to change. It provides
|
||||
up-to-date information for those who are following the 1.1.X branch.
|
||||
|
||||
This is the second "bugfix" release in the Django 1.1 series,
|
||||
improving the stability and performance of the Django 1.1 codebase.
|
||||
|
||||
Django 1.1.2 maintains backwards compatibility with Django
|
||||
1.1.0, but contain a number of fixes and other
|
||||
improvements. Django 1.1.2 is a recommended upgrade for any
|
||||
development or deployment currently using or targeting Django 1.1.
|
||||
|
||||
For full details on the new features, backwards incompatibilities, and
|
||||
deprecated features in the 1.1 branch, see the :ref:`releases-1.1`.
|
||||
|
||||
One new feature
|
||||
---------------
|
||||
|
||||
Ordinarily, a point release would not include new features, but in the
|
||||
case of Django 1.1.2, we have made an exception to this rule. Django
|
||||
1.2 (the next major release of Django) will contain a feature that
|
||||
will improve protection against Cross-Site Request Forgery (CSRF)
|
||||
attacks. This feature requires the use of a new :ttag:`csrf_token`
|
||||
template tag in all forms that Django renders.
|
||||
|
||||
To make it easier to support both 1.1.X and 1.2.X versions of Django with
|
||||
the same templates, we have decided to introduce the :ttag:`csrf_token` template
|
||||
tag to the 1.1.X branch. In the 1.1.X branch, :ttag:`csrf_token` does nothing -
|
||||
it has no effect on templates or form processing. However, it means that the
|
||||
same template will work with Django 1.2.
|
||||
|
|
@ -8,6 +8,11 @@ This page documents release notes for the as-yet-unreleased Django 1.2. As such
|
|||
it is tentative and subject to change. It provides up-to-date information for
|
||||
those who are following trunk.
|
||||
|
||||
Django 1.2 includes a number of nifty `new features`_, lots of bug
|
||||
fixes, and an easy upgrade path from Django 1.1.
|
||||
|
||||
.. _new features: `What's new in Django 1.2`_
|
||||
|
||||
.. _backwards-incompatible-changes-1.2:
|
||||
|
||||
Backwards-incompatible changes in 1.2
|
||||
|
|
@ -68,3 +73,37 @@ Features deprecated in 1.2
|
|||
==========================
|
||||
|
||||
None.
|
||||
|
||||
What's new in Django 1.2
|
||||
========================
|
||||
|
||||
CSRF support
|
||||
------------
|
||||
|
||||
Django now has much improved protection against :ref:`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 :ref:`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-console-backend>`.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
.. _releases-index:
|
||||
|
||||
=============
|
||||
Release notes
|
||||
=============
|
||||
|
||||
|
|
@ -7,37 +8,60 @@ Release notes for the official Django releases. Each release note will tell you
|
|||
what's new in each version, and will also describe any backwards-incompatible
|
||||
changes made in that version.
|
||||
|
||||
For those upgrading to a new version of Django, you will need to check
|
||||
all the backwards-incompatible changes and deprecated features for
|
||||
each 'final' release from the one after your current Django version,
|
||||
up to and including the new version.
|
||||
|
||||
Final releases
|
||||
==============
|
||||
|
||||
1.2 release
|
||||
-----------
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
0.95
|
||||
0.96
|
||||
1.0-alpha-1
|
||||
1.0-alpha-2
|
||||
1.0-beta
|
||||
1.0-beta-2
|
||||
1.0
|
||||
1.0.1
|
||||
1.0.2
|
||||
1.1-alpha-1
|
||||
1.1-beta-1
|
||||
1.1-rc-1
|
||||
1.2
|
||||
|
||||
1.1 release
|
||||
-----------
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
1.1.2
|
||||
1.1
|
||||
|
||||
Upgrading
|
||||
=========
|
||||
1.0 release
|
||||
-----------
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
For those upgrading to a new version of Django, you will need to check all the
|
||||
backwards-incompatible changes and deprecated features for each 'final' release
|
||||
from the one after your old version up to and including your new version. The
|
||||
relevant sections of the release notes are linked below below for your
|
||||
convenience.
|
||||
1.0.2
|
||||
1.0.1
|
||||
1.0
|
||||
|
||||
For those following trunk, the tentative release notes for the next version to
|
||||
be released are also included at the bottom. This is kept up to date with new
|
||||
features and changes that you need to be aware of.
|
||||
Pre-1.0 releases
|
||||
----------------
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
* :ref:`backwards-incompatible-changes-1.1`
|
||||
* :ref:`deprecated-features-1.1`
|
||||
* :ref:`backwards-incompatible-changes-1.2`
|
||||
* :ref:`deprecated-features-1.2`
|
||||
0.96
|
||||
0.95
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -421,6 +421,8 @@ want to specify it explicitly, put the following in your settings::
|
|||
still available in ``django.core.mail`` as an alias for the SMTP backend.
|
||||
New code should use :meth:`~django.core.mail.get_connection` instead.
|
||||
|
||||
.. _topic-email-console-backend:
|
||||
|
||||
Console backend
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -436,6 +438,8 @@ To specify this backend, put the following in your settings::
|
|||
This backend is not intended for use in production -- it is provided as a
|
||||
convenience that can be used during development.
|
||||
|
||||
.. _topic-email-file-backend:
|
||||
|
||||
File backend
|
||||
~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -453,6 +457,8 @@ To specify this backend, put the following in your settings::
|
|||
This backend is not intended for use in production -- it is provided as a
|
||||
convenience that can be used during development.
|
||||
|
||||
.. _topic-email-memory-backend:
|
||||
|
||||
In-memory backend
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -469,6 +475,8 @@ To specify this backend, put the following in your settings::
|
|||
This backend is not intended for use in production -- it is provided as a
|
||||
convenience that can be used during development and testing.
|
||||
|
||||
.. _topic-email-dummy-backend:
|
||||
|
||||
Dummy backend
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue