Removed versionadded/changed annotations for 1.6.

3 files changed, 6 insertions, 48 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