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

docs/index.txt

@@ -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>`

docs/ref/contrib/csrf.txt

@@ -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 %}
@@ -123,14 +123,14 @@ as ``CsrfResponseMiddleware``, and it can be used by following these steps:
 
        ``CsrfResponseMiddleware`` needs to process the response before things
        like compression or setting ofETags happen to the response, so it must
-       come after ``GZipMiddleware``, ``CommonMiddleware`` and 
+       come after ``GZipMiddleware``, ``CommonMiddleware`` and
        ``ConditionalGetMiddleware`` in the list. It also must come after
        ``CsrfViewMiddleware``.
 
 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

docs/ref/templates/builtins.txt

@@ -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
 ~~~~~
 

docs/releases/1.1.2.txt

@@ -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.

docs/releases/1.2.txt

@@ -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>`.
+

docs/releases/index.txt

@@ -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
+
+Pre-1.0 releases
+----------------
+.. toctree::
+   :maxdepth: 1
+
+   0.96
+   0.95
+
+Development releases
+====================
 
-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.
+These notes are retained for historical purposes. If you are upgrading
+between formal Django releases, you don't need to worry about these
+notes.
 
- * :ref:`backwards-incompatible-changes-1.1`
- * :ref:`deprecated-features-1.1`
- * :ref:`backwards-incompatible-changes-1.2`
- * :ref:`deprecated-features-1.2`
+.. 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

docs/topics/email.txt

@@ -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
 ~~~~~~~~~~~~~