Removed versionadded/changed annotations for 1.6.

19 files changed, 21 insertions, 183 deletions

diff --git a/docs/topics/auth/customizing.txt b/docs/topics/auth/customizing.txt
index 55bd4811fd..cc8b944ada 100644
--- a/docs/topics/auth/customizing.txt
+++ b/docs/topics/auth/customizing.txt
@@ -70,6 +70,10 @@ The order of :setting:`AUTHENTICATION_BACKENDS` matters, so if the same
 username and password is valid in multiple backends, Django will stop
 processing at the first positive match.
 
+If a backend raises a :class:`~django.core.exceptions.PermissionDenied`
+exception, authentication will immediately fail. Django won't check the
+backends that follow.
+
 .. note::
 
     Once a user has authenticated, Django stores which backend was used to
@@ -81,12 +85,6 @@ processing at the first positive match.
     you need to force users to re-authenticate using different methods. A simple
     way to do that is simply to execute ``Session.objects.all().delete()``.
 
-.. versionadded:: 1.6
-
-    If a backend raises a :class:`~django.core.exceptions.PermissionDenied`
-    exception, authentication will immediately fail. Django won't check the
-    backends that follow.
-
 Writing an authentication backend
 ---------------------------------
 
@@ -570,23 +568,12 @@ The following methods are available on any subclass of
         :meth:`~django.contrib.auth.models.AbstractBaseUser.set_unusable_password()`
         were used.
 
-        .. versionchanged:: 1.6
-
-            In Django 1.4 and 1.5, a blank string was unintentionally stored
-            as an unusable password as well.
-
     .. method:: models.AbstractBaseUser.check_password(raw_password)
 
         Returns ``True`` if the given raw string is the correct password for
         the user. (This takes care of the password hashing in making the
         comparison.)
 
-        .. versionchanged:: 1.6
-
-            In Django 1.4 and 1.5, a blank string was unintentionally
-            considered to be an unusable password, resulting in this method
-            returning ``False`` for such a password.
-
     .. method:: models.AbstractBaseUser.set_unusable_password()
 
         Marks the user as having no password set.  This isn't the same as
@@ -909,10 +896,6 @@ models provided by ``auth`` app::
             "Run tests for a simple extension of the built-in User."
             self.assertSomething()
 
-.. versionchanged:: 1.6
-
-    In Django 1.5, it wasn't necessary to explicitly import the test User models.
-
 A full example
 --------------
 
diff --git a/docs/topics/auth/default.txt b/docs/topics/auth/default.txt
index 15c895f0aa..58633c556d 100644
--- a/docs/topics/auth/default.txt
+++ b/docs/topics/auth/default.txt
@@ -851,11 +851,6 @@ patterns.
     error message since this would expose their account's existence but no
     mail will be sent either.
 
-    .. versionchanged:: 1.6
-
-        Previously, error messages indicated whether a given email was
-        registered.
-
     **URL name:** ``password_reset``
 
     **Optional arguments:**
@@ -936,15 +931,9 @@ patterns.
         Someone asked for password reset for email {{ email }}. Follow the link below:
         {{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}
 
-    .. versionchanged:: 1.6
-
-      Reversing ``password_reset_confirm`` takes a ``uidb64`` argument instead
-      of ``uidb36``.
-
     The same template context is used for subject template. Subject must be
     single line plain text string.
 
-
 .. function:: password_reset_done(request[, template_name, current_app, extra_context])
 
     The page shown after a user has been emailed a link to reset their
@@ -976,11 +965,6 @@ patterns.
 
     * ``uidb64``: The user's id encoded in base 64. Defaults to ``None``.
 
-      .. versionchanged:: 1.6
-
-          The ``uidb64`` parameter was previously base 36 encoded and named
-          ``uidb36``.
-
     * ``token``: Token to check that the password is valid. Defaults to
       ``None``.
 
diff --git a/docs/topics/auth/passwords.txt b/docs/topics/auth/passwords.txt
index 6ad93a3a84..7ddbc63b9a 100644
--- a/docs/topics/auth/passwords.txt
+++ b/docs/topics/auth/passwords.txt
@@ -183,11 +183,8 @@ can switch to new (and better) storage algorithms as they get invented.
 However, Django can only upgrade passwords that use algorithms mentioned in
 :setting:`PASSWORD_HASHERS`, so as you upgrade to new systems you should make
 sure never to *remove* entries from this list. If you do, users using
-unmentioned algorithms won't be able to upgrade.
-
-.. versionadded:: 1.6
-
-    Passwords will be upgraded when changing the PBKDF2 iteration count.
+unmentioned algorithms won't be able to upgrade. Passwords will be upgraded
+when changing the PBKDF2 iteration count.
 
 .. _sha1: http://en.wikipedia.org/wiki/SHA1
 .. _pbkdf2: http://en.wikipedia.org/wiki/PBKDF2
@@ -214,12 +211,6 @@ from the ``User`` model.
     database to check against, and returns ``True`` if they match, ``False``
     otherwise.
 
-    .. versionchanged:: 1.6
-
-        In Django 1.4 and 1.5, a blank string was unintentionally considered
-        to be an unusable password, resulting in this method returning
-        ``False`` for such a password.
-
 .. function:: make_password(password[, salt, hashers])
 
     Creates a hashed password in the format used by this application. It takes
diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt
index 0d8f957d52..f9623b324b 100644
--- a/docs/topics/cache.txt
+++ b/docs/topics/cache.txt
@@ -771,11 +771,6 @@ of the appropriate backend in the :setting:`CACHES` setting (explained above).
 It's the number of seconds the value should be stored in the cache. Passing in
 ``None`` for ``timeout`` will cache the value forever.
 
-.. versionchanged:: 1.6
-
-    Previously, passing ``None`` explicitly would use the default timeout
-    value.
-
 If the object doesn't exist in the cache, ``cache.get()`` returns ``None``::
 
     # Wait 30 seconds for 'my_key' to expire...
diff --git a/docs/topics/db/managers.txt b/docs/topics/db/managers.txt
index ba9b76c880..705d721c8d 100644
--- a/docs/topics/db/managers.txt
+++ b/docs/topics/db/managers.txt
@@ -179,10 +179,6 @@ your choice of default manager in order to avoid a situation where overriding
 ``get_queryset()`` results in an inability to retrieve objects you'd like to
 work with.
 
-.. versionchanged:: 1.6
-
-    The ``get_queryset`` method was previously named ``get_query_set``.
-
 .. _managers-for-related-objects:
 
 Using managers for related object access
diff --git a/docs/topics/db/sql.txt b/docs/topics/db/sql.txt
index 9dcc98a3cb..2b2b4261f6 100644
--- a/docs/topics/db/sql.txt
+++ b/docs/topics/db/sql.txt
@@ -197,13 +197,6 @@ argument.
 
 __ http://en.wikipedia.org/wiki/SQL_injection
 
-.. versionchanged:: 1.6
-
-    In Django 1.5 and earlier, you could pass parameters as dictionaries
-    when using PostgreSQL or MySQL, although this wasn't documented. Now
-    you can also do this when using Oracle, and it is officially supported.
-
-
 .. _executing-custom-sql:
 
 Executing custom SQL directly
@@ -236,13 +229,6 @@ For example::
 
         return row
 
-.. versionchanged:: 1.6
-
-    In Django 1.5 and earlier, after performing a data changing operation, you
-    had to call ``transaction.commit_unless_managed()`` to ensure your changes
-    were committed to the database. Since Django now defaults to database-level
-    autocommit, this isn't necessary any longer.
-
 Note that if you want to include literal percent signs in the query, you have to
 double them in the case you are passing parameters::
 
diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt
index 9e1c86276f..c4ffa4b35e 100644
--- a/docs/topics/db/transactions.txt
+++ b/docs/topics/db/transactions.txt
@@ -24,11 +24,6 @@ integrity of ORM operations that require multiple queries, especially
 Django's :class:`~django.test.TestCase` class also wraps each test in a
 transaction for performance reasons.
 
-.. versionchanged:: 1.6
-
-    Previous version of Django featured :ref:`a more complicated default
-    behavior <transactions-upgrading-from-1.5>`.
-
 .. _tying-transactions-to-http-requests:
 
 Tying transactions to HTTP requests
@@ -93,16 +88,9 @@ still possible to prevent views from running in a transaction.
 
     It only works if it's applied to the view itself.
 
-.. versionchanged:: 1.6
-
-    Django used to provide this feature via ``TransactionMiddleware``, which is
-    now deprecated.
-
 Controlling transactions explicitly
 -----------------------------------
 
-.. versionadded:: 1.6
-
 Django provides a single API to control database transactions.
 
 .. function:: atomic(using=None, savepoint=True)
@@ -251,11 +239,6 @@ on.
 To avoid this, you can :ref:`deactivate the transaction management
 <deactivate-transaction-management>`, but it isn't recommended.
 
-.. versionchanged:: 1.6
-
-    Before Django 1.6, autocommit was turned off, and it was emulated by
-    forcing a commit after write operations in the ORM.
-
 .. _deactivate-transaction-management:
 
 Deactivating transaction management
@@ -272,10 +255,6 @@ by Django or by third-party libraries. Thus, this is best used in situations
 where you want to run your own transaction-controlling middleware or do
 something really strange.
 
-.. versionchanged:: 1.6
-
-    This used to be controlled by the ``TRANSACTIONS_MANAGED`` setting.
-
 Low-level APIs
 ==============
 
@@ -292,8 +271,6 @@ Low-level APIs
 Autocommit
 ----------
 
-.. versionadded:: 1.6
-
 Django provides a straightforward API in the :mod:`django.db.transaction`
 module to manage the autocommit state of each database connection.
 
@@ -360,12 +337,10 @@ you issue a rollback, the entire transaction is rolled back. Savepoints
 provide the ability to perform a fine-grained rollback, rather than the full
 rollback that would be performed by ``transaction.rollback()``.
 
-.. versionchanged:: 1.6
-
-    When the :func:`atomic` decorator is nested, it creates a savepoint to allow
-    partial commit or rollback. You're strongly encouraged to use :func:`atomic`
-    rather than the functions described below, but they're still part of the
-    public API, and there's no plan to deprecate them.
+When the :func:`atomic` decorator is nested, it creates a savepoint to allow
+partial commit or rollback. You're strongly encouraged to use :func:`atomic`
+rather than the functions described below, but they're still part of the
+public API, and there's no plan to deprecate them.
 
 Each of these functions takes a ``using`` argument which should be the name of
 a database for which the behavior applies.  If no ``using`` argument is
@@ -419,8 +394,6 @@ The following example demonstrates the use of savepoints::
             transaction.savepoint_rollback(sid)
             # open transaction now contains only a.save()
 
-.. versionadded:: 1.6
-
 Savepoints may be used to recover from a database error by performing a partial
 rollback. If you're doing this inside an :func:`atomic` block, the entire block
 will still be rolled back, because it doesn't know you've handled the situation
diff --git a/docs/topics/forms/formsets.txt b/docs/topics/forms/formsets.txt
index 0e32d6131f..44d3154683 100644
--- a/docs/topics/forms/formsets.txt
+++ b/docs/topics/forms/formsets.txt
@@ -118,13 +118,6 @@ affect validation.  If ``validate_max=True`` is passed to the
 :func:`~django.forms.formsets.formset_factory`, then ``max_num`` will affect
 validation.  See :ref:`validate_max`.
 
-.. versionchanged:: 1.6
-
-   The ``validate_max`` parameter was added to
-   :func:`~django.forms.formsets.formset_factory`.  Also, the behavior of
-   ``FormSet`` was brought in line with that of ``ModelFormSet`` so that it
-   displays initial data regardless of ``max_num``.
-
 Formset validation
 ------------------
 
@@ -169,8 +162,6 @@ the expected error message appears for the second item.
 
 .. method:: BaseFormSet.total_error_count()
 
-.. versionadded:: 1.6
-
 To check how many errors there are in the formset, we can use the
 ``total_error_count`` method::
 
@@ -344,11 +335,6 @@ excessive.
     truncated entirely.  This is to protect against memory exhaustion attacks
     using forged POST requests.
 
-.. versionchanged:: 1.6
-
-   The ``validate_max`` parameter was added to
-   :func:`~django.forms.formsets.formset_factory`.
-
 ``validate_min``
 ~~~~~~~~~~~~~~~~
 
diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt
index 441ab2eea3..9d93083f91 100644
--- a/docs/topics/forms/index.txt
+++ b/docs/topics/forms/index.txt
@@ -317,14 +317,11 @@ attributes, which can be useful in your templates:
     The label of the field, e.g. ``Email address``.
 
 ``{{ field.label_tag }}``
-    The field's label wrapped in the appropriate HTML ``<label>`` tag.
+    The field's label wrapped in the appropriate HTML ``<label>`` tag. This
+    includes the form's :attr:`~django.forms.Form.label_suffix`. For example,
+    the default ``label_suffix`` is a colon::
 
-    .. versionchanged:: 1.6
-
-        This includes the form's :attr:`~django.forms.Form.label_suffix`. For
-        example, the default ``label_suffix`` is a colon::
-
-            <label for="id_email">Email address:</label>
+        <label for="id_email">Email address:</label>
 
 ``{{ field.id_for_label }}``
     The ID that will be used for this field (``id_email`` in the example
diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt
index d01fc64cb2..642616d438 100644
--- a/docs/topics/forms/modelforms.txt
+++ b/docs/topics/forms/modelforms.txt
@@ -501,10 +501,6 @@ widget::
 The ``widgets`` dictionary accepts either widget instances (e.g.,
 ``Textarea(...)``) or classes (e.g., ``Textarea``).
 
-.. versionadded:: 1.6
-
-    The ``labels``, ``help_texts`` and ``error_messages`` options were added.
-
 Similarly, you can specify the ``labels``, ``help_texts`` and ``error_messages``
 attributes of the inner ``Meta`` class if you want to further customize a field.
 
@@ -610,8 +606,6 @@ the field declaratively and setting its ``validators`` parameter::
 Enabling localization of fields
 -------------------------------
 
-.. versionadded:: 1.6
-
 By default, the fields in a ``ModelForm`` will not localize their data. To
 enable localization for fields, you can use the ``localized_fields``
 attribute on the ``Meta`` class.
@@ -818,8 +812,6 @@ exclude::
 Specifying widgets to use in the form with ``widgets``
 ------------------------------------------------------
 
-.. versionadded:: 1.6
-
 Using the ``widgets`` parameter, you can specify a dictionary of values to
 customize the ``ModelForm``’s widget class for a particular field. This
 works the same way as the ``widgets`` dictionary on the inner ``Meta``
@@ -831,8 +823,6 @@ class of a ``ModelForm`` works::
 Enabling localization for fields with ``localized_fields``
 ----------------------------------------------------------
 
-.. versionadded:: 1.6
-
 Using the ``localized_fields`` parameter, you can enable localization for
 fields in the form.
 
@@ -1196,9 +1186,9 @@ Notice how we pass ``instance`` in both the ``POST`` and ``GET`` cases.
 Specifying widgets to use in the inline form
 --------------------------------------------
 
-.. versionadded:: 1.6
 
 ``inlineformset_factory`` uses ``modelformset_factory`` and passes most
 of its arguments to ``modelformset_factory``. This means you can use
 the ``widgets`` parameter in much the same way as passing it to
-``modelformset_factory``. See `Specifying widgets to use in the form with widgets`_ above.
+``modelformset_factory``. See `Specifying widgets to use in the form with
+widgets`_ above.
diff --git a/docs/topics/http/middleware.txt b/docs/topics/http/middleware.txt
index b18573f002..e21bdbd297 100644
--- a/docs/topics/http/middleware.txt
+++ b/docs/topics/http/middleware.txt
@@ -8,8 +8,8 @@ or output.
 
 Each middleware component is responsible for doing some specific function. For
 example, Django includes a middleware component,
-:class:`~django.middleware.transaction.TransactionMiddleware`, that wraps the
-processing of each HTTP request in a database transaction.
+:class:`~django.contrib.auth.middleware.AuthenticationMiddleware`, that
+associates users with requests using sessions.
 
 This document explains how middleware works, how you activate middleware, and
 how to write your own middleware. Django ships with some built-in middleware
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index 5711b0c490..864777bfe4 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -324,8 +324,6 @@ You can edit it multiple times.
 Session serialization
 ---------------------
 
-.. versionchanged:: 1.6
-
 Before version 1.6, Django defaulted to using :mod:`pickle` to serialize
 session data before storing it in the backend. If you're using the :ref:`signed
 cookie session backend<cookie-session-backend>` and :setting:`SECRET_KEY` is
diff --git a/docs/topics/http/views.txt b/docs/topics/http/views.txt
index 28f2abdc9a..0653d74f53 100644
--- a/docs/topics/http/views.txt
+++ b/docs/topics/http/views.txt
@@ -242,8 +242,6 @@ same way you can for the 404 and 500 views by specifying a
 The 400 (bad request) view
 --------------------------
 
-.. versionadded:: 1.6
-
 .. function:: django.views.defaults.bad_request(request, template_name='400.html')
 
 When a :exc:`~django.core.exceptions.SuspiciousOperation` is raised in Django,
diff --git a/docs/topics/i18n/translation.txt b/docs/topics/i18n/translation.txt
index 6dae9f691f..16742ab622 100644
--- a/docs/topics/i18n/translation.txt
+++ b/docs/topics/i18n/translation.txt
@@ -433,8 +433,6 @@ helper function described next.
 Lazy translations and plural
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. versionadded:: 1.6
-
 When using lazy translation for a plural string (``[u]n[p]gettext_lazy``), you
 generally don't know the ``number`` argument at the time of the string
 definition. Therefore, you are authorized to pass a key name instead of an
diff --git a/docs/topics/logging.txt b/docs/topics/logging.txt
index 751563e4b9..d7e6b073af 100644
--- a/docs/topics/logging.txt
+++ b/docs/topics/logging.txt
@@ -531,8 +531,6 @@ Python logging module.
     sensitive information to be filtered out of error reports -- learn more on
     :ref:`Filtering error reports<filtering-error-reports>`.
 
-    .. versionadded:: 1.6
-
     By setting the ``email_backend`` argument of ``AdminEmailHandler``, the
     :ref:`email backend <topic-email-backends>` that is being used by the
     handler can be overridden, like this::
diff --git a/docs/topics/serialization.txt b/docs/topics/serialization.txt
index 2435289b16..6a89ae4141 100644
--- a/docs/topics/serialization.txt
+++ b/docs/topics/serialization.txt
@@ -122,11 +122,6 @@ Calling ``DeserializedObject.save()`` saves the object to the database.
     If the ``pk`` attribute in the serialized data doesn't exist or is
     null, a new instance will be saved to the database.
 
-.. versionchanged:: 1.6
-
-    In previous versions of Django, the ``pk`` attribute had to be present
-    on the serialized data or a ``DeserializationError`` would be raised.
-
 This ensures that deserializing is a non-destructive operation even if the
 data in your serialized representation doesn't match what's currently in the
 database. Usually, working with these ``DeserializedObject`` instances looks
diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt
index 1bd15bd1a6..cd71505d38 100644
--- a/docs/topics/testing/advanced.txt
+++ b/docs/topics/testing/advanced.txt
@@ -166,8 +166,6 @@ Advanced features of ``TransactionTestCase``
 
 .. attribute:: TransactionTestCase.available_apps
 
-    .. versionadded:: 1.6
-
     .. warning::
 
         This attribute is a private API. It may be changed or removed without
@@ -295,8 +293,6 @@ Defining a test runner
 
 .. currentmodule:: django.test.runner
 
-.. versionadded:: 1.6
-
 A test runner is a class defining a ``run_tests()`` method. Django ships
 with a ``DiscoverRunner`` class that defines the default Django testing
 behavior. This class defines the ``run_tests()`` entry point, plus a
diff --git a/docs/topics/testing/overview.txt b/docs/topics/testing/overview.txt
index 19fff1ed1c..30448e9db9 100644
--- a/docs/topics/testing/overview.txt
+++ b/docs/topics/testing/overview.txt
@@ -58,12 +58,6 @@ test utility is to find all the test cases (that is, subclasses of
 :class:`unittest.TestCase`) in any file whose name begins with ``test``,
 automatically build a test suite out of those test cases, and run that suite.
 
-.. versionchanged:: 1.6
-
-   Previously, Django's default test runner only discovered tests in
-   ``tests.py`` and ``models.py`` files within a Python package listed in
-   :setting:`INSTALLED_APPS`.
-
 For more details about :mod:`unittest`, see the Python documentation.
 
 .. warning::
@@ -120,15 +114,6 @@ You can specify a custom filename pattern match using the ``-p`` (or
 
     $ ./manage.py test --pattern="tests_*.py"
 
-.. versionchanged:: 1.6
-
-   Previously, test labels were in the form ``applabel``,
-   ``applabel.TestCase``, or ``applabel.TestCase.test_method``, rather than
-   being true Python dotted paths, and tests could only be found within
-   ``tests.py`` or ``models.py`` files within a Python package listed in
-   :setting:`INSTALLED_APPS`. The ``--pattern`` option and file paths as test
-   labels are new in 1.6.
-
 If you press ``Ctrl-C`` while the tests are running, the test runner will
 wait for the currently running test to complete and then exit gracefully.
 During a graceful exit the test runner will output details of any test
diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt
index a67675b268..f56cbee861 100644
--- a/docs/topics/testing/tools.txt
+++ b/docs/topics/testing/tools.txt
@@ -573,11 +573,6 @@ functionality like:
 * Using the :attr:`~SimpleTestCase.client` :class:`~django.test.Client`.
 * Custom test-time :attr:`URL maps <SimpleTestCase.urls>`.
 
-.. versionchanged:: 1.6
-
-    The latter two features were moved from ``TransactionTestCase`` to
-    ``SimpleTestCase`` in Django 1.6.
-
 If you need any of the other more complex and heavyweight Django-specific
 features like:
 
@@ -1281,8 +1276,6 @@ your test suite.
 
 .. method:: SimpleTestCase.assertFormsetError(response, formset, form_index, field, errors, msg_prefix='')
 
-    .. versionadded:: 1.6
-
     Asserts that the ``formset`` raises the provided list of errors when
     rendered.
 
@@ -1459,16 +1452,12 @@ your test suite.
     By default, the comparison is also ordering dependent. If ``qs`` doesn't
     provide an implicit ordering, you can set the ``ordered`` parameter to
     ``False``, which turns the comparison into a Python set comparison.
+    If the order is undefined (if the given ``qs`` isn't ordered and the
+    comparison is against more than one ordered values), a ``ValueError`` is
+    raised.
 
     Output in case of error can be customized with the ``msg`` argument.
 
-    .. versionchanged:: 1.6
-
-        The method now checks for undefined order and raises ``ValueError``
-        if undefined order is spotted. The ordering is seen as undefined if
-        the given ``qs`` isn't ordered and the comparison is against more
-        than one ordered values.
-
     .. versionchanged:: 1.7
 
         The method now accepts a ``msg`` parameter to allow customization of