18 files changed, 33 insertions, 145 deletions
diff --git a/docs/topics/auth/customizing.txt b/docs/topics/auth/customizing.txt
index e92e775bda..746e92e637 100644
--- a/docs/topics/auth/customizing.txt
+++ b/docs/topics/auth/customizing.txt
@@ -359,8 +359,6 @@ the extra database load.
 Substituting a custom User model
 ================================
 
-.. versionadded:: 1.5
-
 Some kinds of projects may have authentication requirements for which Django's
 built-in :class:`~django.contrib.auth.models.User` model is not always
 appropriate. For instance, on some sites it makes more sense to use an email
@@ -684,13 +682,13 @@ auth views.
 * :class:`~django.contrib.auth.forms.AuthenticationForm`
 
   Works with any subclass of :class:`~django.contrib.auth.models.AbstractBaseUser`,
-  and will adapt to use the field defined in `USERNAME_FIELD`.
+  and will adapt to use the field defined in ``USERNAME_FIELD``.
 
 * :class:`~django.contrib.auth.forms.PasswordResetForm`
 
   Assumes that the user model has an integer primary key, has a field named
   ``email`` that can be used to identify the user, and a boolean field
-  named `is_active` to prevent password resets for inactive users.
+  named ``is_active`` to prevent password resets for inactive users.
 
 * :class:`~django.contrib.auth.forms.SetPasswordForm`
 
diff --git a/docs/topics/auth/default.txt b/docs/topics/auth/default.txt
index 902adc9e32..4d86a7330e 100644
--- a/docs/topics/auth/default.txt
+++ b/docs/topics/auth/default.txt
@@ -434,12 +434,10 @@ The login_required decorator
 
         (r'^accounts/login/$', 'django.contrib.auth.views.login'),
 
-    .. versionchanged:: 1.5
-
-        The :setting:`settings.LOGIN_URL <LOGIN_URL>` also accepts
-        view function names and :ref:`named URL patterns <naming-url-patterns>`.
-        This allows you to freely remap your login view within your URLconf
-        without having to update the setting.
+    The :setting:`settings.LOGIN_URL <LOGIN_URL>` also accepts view function
+    names and :ref:`named URL patterns <naming-url-patterns>`. This allows you
+    to freely remap your login view within your URLconf without having to
+    update the setting.
 
 .. note::
 
@@ -528,6 +526,11 @@ The permission_required decorator
     (HTTP Forbidden) view<http_forbidden_view>` instead of redirecting to the
     login page.
 
+    .. versionchanged:: 1.7
+
+        The :func:`~django.contrib.auth.decorators.permission_required`
+        decorator can take a list of permissions as well as a single permission.
+
 Applying permissions to generic views
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -1182,10 +1185,6 @@ Thus, you can check permissions in template ``{% if %}`` statements:
         <p>You don't have permission to do anything in the foo app.</p>
     {% endif %}
 
-.. versionadded:: 1.5
-
-    Permission lookup by "if in".
-
 It is possible to also look permissions up by ``{% if in %}`` statements.
 For example:
 
diff --git a/docs/topics/class-based-views/intro.txt b/docs/topics/class-based-views/intro.txt
index a65b887921..5986ff2ea7 100644
--- a/docs/topics/class-based-views/intro.txt
+++ b/docs/topics/class-based-views/intro.txt
@@ -198,6 +198,7 @@ A similar class-based view might look like::
 
     from django.http import HttpResponseRedirect
     from django.shortcuts import render
+    from django.views.generic.base import View
 
     from .forms import MyForm
 
diff --git a/docs/topics/class-based-views/mixins.txt b/docs/topics/class-based-views/mixins.txt
index fdd5d42c5d..fb0b388b57 100644
--- a/docs/topics/class-based-views/mixins.txt
+++ b/docs/topics/class-based-views/mixins.txt
@@ -55,8 +55,6 @@ interface to working with templates in class-based views.
     override this to provide more flexible defaults when dealing with actual
     objects.
 
-.. versionadded:: 1.5
-
 :class:`~django.views.generic.base.ContextMixin`
     Every built in view which needs context data, such as for rendering a
     template (including ``TemplateResponseMixin`` above), should call
diff --git a/docs/topics/db/managers.txt b/docs/topics/db/managers.txt
index 2d3f35db8b..c97149cfd1 100644
--- a/docs/topics/db/managers.txt
+++ b/docs/topics/db/managers.txt
@@ -265,8 +265,8 @@ Methods are copied according to the following rules:
 
 - Public methods are copied by default.
 - Private methods (starting with an underscore) are not copied by default.
-- Methods with a `queryset_only` attribute set to `False` are always copied.
-- Methods with a `queryset_only` attribute set to `True` are never copied.
+- Methods with a ``queryset_only`` attribute set to ``False`` are always copied.
+- Methods with a ``queryset_only`` attribute set to ``True`` are never copied.
 
 For example::
 
diff --git a/docs/topics/db/multi-db.txt b/docs/topics/db/multi-db.txt
index 6e19844b5c..c098aa33e3 100644
--- a/docs/topics/db/multi-db.txt
+++ b/docs/topics/db/multi-db.txt
@@ -689,11 +689,6 @@ In addition, some objects are automatically created just after
 - three ``Permission`` for each model (including those not stored in that
   database).
 
-.. versionchanged:: 1.5
-
-    Previously, ``ContentType`` and ``Permission`` instances were created only
-    in the default database.
-
 For common setups with multiple databases, it isn't useful to have these
 objects in more than one database. Common setups include master / slave and
 connecting to external databases. Therefore, it's recommended:
diff --git a/docs/topics/db/queries.txt b/docs/topics/db/queries.txt
index 9a0d0ce6b9..30335f266d 100644
--- a/docs/topics/db/queries.txt
+++ b/docs/topics/db/queries.txt
@@ -639,20 +639,11 @@ that were modified more than 3 days after they were published::
     >>> from datetime import timedelta
     >>> Entry.objects.filter(mod_date__gt=F('pub_date') + timedelta(days=3))
 
-.. versionadded:: 1.5
-
-    ``.bitand()`` and ``.bitor()``
-
-The ``F()`` objects now support bitwise operations by ``.bitand()`` and
+The ``F()`` objects support bitwise operations by ``.bitand()`` and
 ``.bitor()``, for example::
 
     >>> F('somefield').bitand(16)
 
-.. versionchanged:: 1.5
-
-    The previously undocumented operators ``&`` and ``|`` no longer produce
-    bitwise operations, use ``.bitand()`` and ``.bitor()`` instead.
-
 The pk lookup shortcut
 ----------------------
 
diff --git a/docs/topics/http/file-uploads.txt b/docs/topics/http/file-uploads.txt
index 2cdab9ea9b..d88524ee20 100644
--- a/docs/topics/http/file-uploads.txt
+++ b/docs/topics/http/file-uploads.txt
@@ -132,7 +132,7 @@ upload behavior.
 Changing upload handler behavior
 --------------------------------
 
-Three settings control Django's file upload behavior:
+There are a few settings which control Django's file upload behavior:
 
 :setting:`FILE_UPLOAD_MAX_MEMORY_SIZE`
     The maximum size, in bytes, for files that will be uploaded into memory.
@@ -167,6 +167,11 @@ Three settings control Django's file upload behavior:
 
         **Always prefix the mode with a 0.**
 
+:setting:`FILE_UPLOAD_DIRECTORY_PERMISSIONS`
+    The numeric mode to apply to directories created in the process of
+    uploading files. This value mirrors the functionality and caveats of
+    the :setting:`FILE_UPLOAD_PERMISSIONS` setting.
+
 :setting:`FILE_UPLOAD_HANDLERS`
     The actual handlers for uploaded files. Changing this setting allows
     complete customization -- even replacement -- of Django's upload
diff --git a/docs/topics/http/middleware.txt b/docs/topics/http/middleware.txt
index 6bb7ccb8f8..da3f7ce4c1 100644
--- a/docs/topics/http/middleware.txt
+++ b/docs/topics/http/middleware.txt
@@ -204,11 +204,6 @@ reverse order, from the bottom up. This means classes defined at the end of
 Dealing with streaming responses
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. versionchanged:: 1.5
-
-    ``response`` may also be an :class:`~django.http.StreamingHttpResponse`
-    object.
-
 Unlike :class:`~django.http.HttpResponse`,
 :class:`~django.http.StreamingHttpResponse` does not have a ``content``
 attribute. As a result, middleware can no longer assume that all responses
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index 3ee7af9539..6ac17ccbd8 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -70,10 +70,6 @@ If you have multiple caches defined in :setting:`CACHES`, Django will use the
 default cache. To use another cache, set :setting:`SESSION_CACHE_ALIAS` to the
 name of that cache.
 
-.. versionchanged:: 1.5
-
-    The :setting:`SESSION_CACHE_ALIAS` setting was added.
-
 Once your cache is configured, you've got two choices for how to store data in
 the cache:
 
@@ -302,8 +298,6 @@ You can edit it multiple times.
 
     .. method:: SessionBase.clear_expired
 
-      .. versionadded:: 1.5
-
       Removes expired sessions from the session store. This class method is
       called by :djadmin:`clearsessions`.
 
@@ -469,9 +463,7 @@ cookie will be sent on every request.
 Similarly, the ``expires`` part of a session cookie is updated each time the
 session cookie is sent.
 
-.. versionchanged:: 1.5
-
-  The session is not saved if the response's status code is 500.
+The session is not saved if the response's status code is 500.
 
 .. _browser-length-vs-persistent-sessions:
 
diff --git a/docs/topics/http/shortcuts.txt b/docs/topics/http/shortcuts.txt
index 5c8725172a..8a80affb2a 100644
--- a/docs/topics/http/shortcuts.txt
+++ b/docs/topics/http/shortcuts.txt
@@ -21,7 +21,7 @@ introduce controlled coupling for convenience's sake.
    :class:`~django.http.HttpResponse` object with that rendered text.
 
    :func:`render()` is the same as a call to
-   :func:`render_to_response()` with a `context_instance` argument that
+   :func:`render_to_response()` with a ``context_instance`` argument that
    forces the use of a :class:`~django.template.RequestContext`.
 
 Required arguments
@@ -50,10 +50,6 @@ Optional arguments
     The MIME type to use for the resulting document. Defaults to the value of
     the :setting:`DEFAULT_CONTENT_TYPE` setting.
 
-    .. versionchanged:: 1.5
-
-        This parameter used to be called ``mimetype``.
-
 ``status``
     The status code for the response. Defaults to ``200``.
 
@@ -129,11 +125,6 @@ Optional arguments
     The MIME type to use for the resulting document. Defaults to the value of
     the :setting:`DEFAULT_CONTENT_TYPE` setting.
 
-    .. versionchanged:: 1.5
-
-        This parameter used to be called ``mimetype``.
-
-
 Example
 -------
 
@@ -169,7 +160,8 @@ This example is equivalent to::
 
    The arguments could be:
 
-   * A model: the model's `get_absolute_url()` function will be called.
+   * A model: the model's `:meth:`~django.db.models.Model.get_absolute_url()`
+     function will be called.
 
    * A view name, possibly with arguments: :func:`urlresolvers.reverse
      <django.core.urlresolvers.reverse>` will be used to reverse-resolve the
diff --git a/docs/topics/i18n/translation.txt b/docs/topics/i18n/translation.txt
index e724837ce1..6436e7dcf9 100644
--- a/docs/topics/i18n/translation.txt
+++ b/docs/topics/i18n/translation.txt
@@ -1031,8 +1031,6 @@ in django-statici18n_.
 Internationalization: in URL patterns
 =====================================
 
-..  versionadded:: 1.4
-
 .. module:: django.conf.urls.i18n
 
 Django provides two mechanisms to internationalize URL patterns:
diff --git a/docs/topics/logging.txt b/docs/topics/logging.txt
index 66c517d615..21eac6e120 100644
--- a/docs/topics/logging.txt
+++ b/docs/topics/logging.txt
@@ -581,8 +581,6 @@ logging module.
 
 .. class:: RequireDebugTrue()
 
-   .. versionadded:: 1.5
-
    This filter is similar to :class:`RequireDebugFalse`, except that records are
    passed only when :setting:`DEBUG` is ``True``.
 
@@ -599,10 +597,5 @@ All messages reaching the ``django`` catch-all logger when :setting:`DEBUG` is
 ``True`` are sent to the console. They are simply discarded (sent to
 ``NullHandler``) when :setting:`DEBUG` is ``False``.
 
-.. versionchanged:: 1.5
-
-    Before Django 1.5, all messages reaching the ``django`` logger were
-    discarded, regardless of :setting:`DEBUG`.
-
 See also :ref:`Configuring logging <configuring-logging>` to learn how you can
 complement or replace this default logging configuration.
diff --git a/docs/topics/pagination.txt b/docs/topics/pagination.txt
index 9da71563c3..f3c8e35c25 100644
--- a/docs/topics/pagination.txt
+++ b/docs/topics/pagination.txt
@@ -248,19 +248,13 @@ Methods
 
 .. method:: Page.next_page_number()
 
-    Returns the next page number.
-
-    .. versionchanged:: 1.5
-
-        Raises :exc:`InvalidPage` if next page doesn't exist.
+    Returns the next page number. Raises :exc:`InvalidPage` if next page
+    doesn't exist.
 
 .. method:: Page.previous_page_number()
 
-    Returns the previous page number.
-
-    .. versionchanged:: 1.5
-
-        Raises :exc:`InvalidPage` if previous page doesn't exist.
+    Returns the previous page number. Raises :exc:`InvalidPage` if previous
+    page doesn't exist.
 
 .. method:: Page.start_index()
 
diff --git a/docs/topics/serialization.txt b/docs/topics/serialization.txt
index d3fda16479..0f24715599 100644
--- a/docs/topics/serialization.txt
+++ b/docs/topics/serialization.txt
@@ -141,14 +141,11 @@ sure that they are "appropriate" for saving before doing so.  Of course, if you
 trust your data source you could just save the object and move on.
 
 The Django object itself can be inspected as ``deserialized_object.object``.
+If fields in the serialized data do not exist on a model, a
+``DeserializationError`` will be raised unless the ``ignorenonexistent``
+argument is passed in as ``True``::
 
-.. versionadded:: 1.5
-
-    If fields in the serialized data do not exist on a model,
-    a ``DeserializationError`` will be raised unless the ``ignorenonexistent``
-    argument is passed in as True::
-
-        serializers.deserialize("xml", data, ignorenonexistent=True)
+    serializers.deserialize("xml", data, ignorenonexistent=True)
 
 .. _serialization-formats:
 
diff --git a/docs/topics/signals.txt b/docs/topics/signals.txt
index a97fb2f14f..587590096c 100644
--- a/docs/topics/signals.txt
+++ b/docs/topics/signals.txt
@@ -132,10 +132,6 @@ Now, our ``my_callback`` function will be called each time a request finishes.
 Note that ``receiver`` can also take a list of signals to connect a function
 to.
 
-.. versionchanged:: 1.5
-
-    The ability to pass a list of signals was added.
-
 .. admonition:: Where should this code live?
 
     You can put signal handling and registration code anywhere you like.
diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt
index 99af951866..d8d59c6872 100644
--- a/docs/topics/testing/advanced.txt
+++ b/docs/topics/testing/advanced.txt
@@ -217,8 +217,6 @@ Advanced features of ``TransactionTestCase``
 
 .. attribute:: TransactionTestCase.reset_sequences
 
-    .. versionadded:: 1.5
-
     Setting ``reset_sequences = True`` on a ``TransactionTestCase`` will make
     sure sequences are always reset before the test run::
 
diff --git a/docs/topics/testing/overview.txt b/docs/topics/testing/overview.txt
index 457d10eec0..dc12244d72 100644
--- a/docs/topics/testing/overview.txt
+++ b/docs/topics/testing/overview.txt
@@ -219,12 +219,6 @@ the Django test runner reorders tests in the following way:
 * Then any other tests (e.g. doctests) that may alter the database without
   restoring it to its original state are run.
 
-.. versionchanged:: 1.5
-
-    Before Django 1.5, the only guarantee was that
-    :class:`~django.test.TestCase` tests were always ran first, before any other
-    tests.
-
 .. note::
 
     The new ordering of tests may reveal unexpected dependencies on test case
@@ -587,11 +581,6 @@ Use the ``django.test.client.Client`` class to make requests.
         When ``data`` is provided, it is used as the request body, and
         a ``Content-Type`` header is set to ``content_type``.
 
-        .. versionchanged:: 1.5
-
-            :meth:`Client.options` used to process ``data`` like
-            :meth:`Client.get`.
-
         The ``follow`` and ``extra`` arguments act the same as for
         :meth:`Client.get`.
 
@@ -603,11 +592,6 @@ Use the ``django.test.client.Client`` class to make requests.
         When ``data`` is provided, it is used as the request body, and
         a ``Content-Type`` header is set to ``content_type``.
 
-        .. versionchanged:: 1.5
-
-            :meth:`Client.put` used to process ``data`` like
-            :meth:`Client.post`.
-
         The ``follow`` and ``extra`` arguments act the same as for
         :meth:`Client.get`.
 
@@ -627,15 +611,9 @@ Use the ``django.test.client.Client`` class to make requests.
         When ``data`` is provided, it is used as the request body, and
         a ``Content-Type`` header is set to ``content_type``.
 
-        .. versionchanged:: 1.5
-
-            :meth:`Client.delete` used to process ``data`` like
-            :meth:`Client.get`.
-
         The ``follow`` and ``extra`` arguments act the same as for
         :meth:`Client.get`.
 
-
     .. method:: Client.login(**credentials)
 
         If your site uses Django's :doc:`authentication system</topics/auth/index>`
@@ -931,25 +909,6 @@ to test the effects of commit and rollback:
     database. This can cause your tests to pass or fail unexpectedly. Always
     use ``TransactionTestCase`` when testing transactional behavior.
 
-.. versionchanged:: 1.5
-
-    Prior to 1.5, :class:`~django.test.TransactionTestCase` flushed the
-    database tables *before* each test. In Django 1.5, this is instead done
-    *after* the test has been run.
-
-    When the flush took place before the test, it was guaranteed that primary
-    key values started at one in :class:`~django.test.TransactionTestCase`
-    tests.
-
-    Tests should not depend on this behavior, but for legacy tests that do,
-    the :attr:`~TransactionTestCase.reset_sequences` attribute can be used
-    until the test has been properly updated.
-
-.. versionchanged:: 1.5
-
-    The order in which tests are run has changed. See `Order in which tests are
-    executed`_.
-
 ``TransactionTestCase`` inherits from :class:`~django.test.SimpleTestCase`.
 
 TestCase
@@ -975,11 +934,6 @@ additions, including:
 * Django-specific assertions for testing for things like redirection and form
   errors.
 
-.. versionchanged:: 1.5
-
-    The order in which tests are run has changed. See `Order in which tests are
-    executed`_.
-
 ``TestCase`` inherits from :class:`~django.test.TransactionTestCase`.
 
 .. _live-test-server:
@@ -1636,8 +1590,6 @@ your test suite.
 
 .. method:: SimpleTestCase.assertXMLEqual(xml1, xml2, msg=None)
 
-    .. versionadded:: 1.5
-
     Asserts that the strings ``xml1`` and ``xml2`` are equal. The
     comparison is based on XML semantics. Similarly to
     :meth:`~SimpleTestCase.assertHTMLEqual`, the comparison is
@@ -1649,8 +1601,6 @@ your test suite.
 
 .. method:: SimpleTestCase.assertXMLNotEqual(xml1, xml2, msg=None)
 
-    .. versionadded:: 1.5
-
     Asserts that the strings ``xml1`` and ``xml2`` are *not* equal. The
     comparison is based on XML semantics. See
     :meth:`~SimpleTestCase.assertXMLEqual` for details.
@@ -1659,8 +1609,6 @@ your test suite.
 
 .. method:: SimpleTestCase.assertInHTML(needle, haystack, count=None, msg_prefix='')
 
-    .. versionadded:: 1.5
-
     Asserts that the HTML fragment ``needle`` is contained in the ``haystack`` one.
 
     If the ``count`` integer argument is specified, then additionally the number
@@ -1671,8 +1619,6 @@ your test suite.
 
 .. method:: SimpleTestCase.assertJSONEqual(raw, expected_data, msg=None)
 
-    .. versionadded:: 1.5
-
     Asserts that the JSON fragments ``raw`` and ``expected_data`` are equal.
     Usual JSON non-significant whitespace rules apply as the heavyweight is
     delegated to the :mod:`json` library.