Removed versionadded/changed notes for 1.7.

22 files changed, 55 insertions, 310 deletions

diff --git a/docs/topics/auth/customizing.txt b/docs/topics/auth/customizing.txt
index 1a5e33f3ba..d75b4b6cb8 100644
--- a/docs/topics/auth/customizing.txt
+++ b/docs/topics/auth/customizing.txt
@@ -436,18 +436,16 @@ different User model.
         class Article(models.Model):
             author = models.ForeignKey(settings.AUTH_USER_MODEL)
 
-    .. versionadded:: 1.7
+    When connecting to signals sent by the ``User`` model, you should specify
+    the custom model using the :setting:`AUTH_USER_MODEL` setting. For example::
 
-        When connecting to signals sent by the User model, you should specify the
-        custom model using the :setting:`AUTH_USER_MODEL` setting. For example::
-
-            from django.conf import settings
-            from django.db.models.signals import post_save
+        from django.conf import settings
+        from django.db.models.signals import post_save
 
-            def post_save_receiver(signal, sender, instance, **kwargs):
-                pass
+        def post_save_receiver(signal, sender, instance, **kwargs):
+            pass
 
-            post_save.connect(post_save_receiver, sender=settings.AUTH_USER_MODEL)
+        post_save.connect(post_save_receiver, sender=settings.AUTH_USER_MODEL)
 
     Generally speaking, you should reference the User model with the
     :setting:`AUTH_USER_MODEL` setting in code that is executed at import
@@ -637,8 +635,6 @@ The following methods are available on any subclass of
 
     .. method:: models.AbstractBaseUser.get_session_auth_hash()
 
-        .. versionadded:: 1.7
-
         Returns an HMAC of the password field. Used for
         :ref:`session-invalidation-on-password-change`.
 
diff --git a/docs/topics/auth/default.txt b/docs/topics/auth/default.txt
index aed6187a37..f7bc764d47 100644
--- a/docs/topics/auth/default.txt
+++ b/docs/topics/auth/default.txt
@@ -108,8 +108,6 @@ Django also provides :ref:`views <built-in-auth-views>` and :ref:`forms
 <built-in-auth-forms>` that may be used to allow users to change their own
 passwords.
 
-.. versionadded:: 1.7
-
 Changing a user's password will log out all their sessions if the
 :class:`~django.contrib.auth.middleware.SessionAuthenticationMiddleware` is
 enabled. See :ref:`session-invalidation-on-password-change` for details.
@@ -560,11 +558,13 @@ The permission_required decorator
         def my_view(request):
             ...
 
-    As for the :meth:`~django.contrib.auth.models.User.has_perm` method,
+    Just like the :meth:`~django.contrib.auth.models.User.has_perm` method,
     permission names take the form ``"<app label>.<permission codename>"``
     (i.e. ``polls.can_vote`` for a permission on a model in the ``polls``
     application).
 
+    The decorator may also take a list of permissions.
+
     Note that :func:`~django.contrib.auth.decorators.permission_required()`
     also takes an optional ``login_url`` parameter. Example::
 
@@ -582,11 +582,6 @@ 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:
 
 Applying permissions to generic views
@@ -603,8 +598,6 @@ To apply a permission to a :doc:`class-based generic view
 Session invalidation on password change
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. versionadded:: 1.7
-
 .. warning::
 
     This protection only applies if
@@ -986,10 +979,6 @@ patterns.
       for generating a ``text/html`` multipart email with the password reset
       link. By default, HTML email is not sent.
 
-    .. versionadded:: 1.7
-
-        ``html_email_template_name`` was added.
-
     .. deprecated:: 1.8
 
         The ``is_admin_site`` argument is deprecated and will be removed in
@@ -1177,8 +1166,6 @@ provides several built-in forms located in :mod:`django.contrib.auth.forms`:
 
     .. method:: confirm_login_allowed(user)
 
-        .. versionadded:: 1.7
-
         By default, ``AuthenticationForm`` rejects users whose ``is_active`` flag
         is set to ``False``. You may override this behavior with a custom policy to
         determine which users can log in. Do this with a custom form that subclasses
diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt
index f638149b95..d6c5c56f6f 100644
--- a/docs/topics/cache.txt
+++ b/docs/topics/cache.txt
@@ -206,13 +206,6 @@ If you are using multiple databases, :djadmin:`createcachetable` observes the
 Like :djadmin:`migrate`, :djadmin:`createcachetable` won't touch an existing
 table. It will only create missing tables.
 
-.. versionchanged:: 1.7
-
-    Before Django 1.7, :djadmin:`createcachetable` created one table at a time.
-    You had to pass the name of the table you wanted to create, and if you were
-    using multiple databases, you had to use the :djadminopt:`--database`
-    option. For backwards compatibility, this is still possible.
-
 Multiple databases
 ~~~~~~~~~~~~~~~~~~
 
@@ -369,9 +362,6 @@ behavior. These arguments are provided as additional keys in the
 
 * :setting:`TIMEOUT <CACHES-TIMEOUT>`: The default timeout, in
   seconds, to use for the cache. This argument defaults to ``300`` seconds (5 minutes).
-
-  .. versionadded:: 1.7
-
   You can set ``TIMEOUT`` to ``None`` so that, by default, cache keys never
   expire.
 
@@ -662,12 +652,10 @@ equivalent:
 This feature is useful in avoiding repetition in templates. You can set the
 timeout in a variable, in one place, and just reuse that value.
 
-.. versionadded:: 1.7
-
-    By default, the cache tag will try to use the cache called
-    "template_fragments". If no such cache exists, it will fall back to using
-    the default cache. You may select an alternate cache backend to use with
-    the ``using`` keyword argument, which must be the last argument to the tag.
+By default, the cache tag will try to use the cache called "template_fragments".
+If no such cache exists, it will fall back to using the default cache. You may
+select an alternate cache backend to use with the ``using`` keyword argument,
+which must be the last argument to the tag.
 
 .. code-block:: html+django
 
@@ -719,8 +707,6 @@ Accessing the cache
 
 .. data:: django.core.cache.caches
 
-    .. versionadded:: 1.7
-
     You can access the caches configured in the :setting:`CACHES` setting
     through a dict-like object: ``django.core.cache.caches``. Repeated
     requests for the same alias in the same thread will return the same
@@ -1048,11 +1034,6 @@ produces different content based on some difference in request headers -- such
 as a cookie, or a language, or a user-agent -- you'll need to use the ``Vary``
 header to tell caching mechanisms that the page output depends on those things.
 
-.. versionchanged:: 1.7
-
-    Cache keys use the request's fully-qualified URL rather than just the path
-    and query string.
-
 To do this in Django, use the convenient
 :func:`django.views.decorators.vary.vary_on_headers` view decorator, like so::
 
diff --git a/docs/topics/checks.txt b/docs/topics/checks.txt
index 56bb6dfc07..c553577310 100644
--- a/docs/topics/checks.txt
+++ b/docs/topics/checks.txt
@@ -2,8 +2,6 @@
 System check framework
 ======================
 
-.. versionadded:: 1.7
-
 .. module:: django.core.checks
 
 The system check framework is a set of static checks for validating Django
diff --git a/docs/topics/db/managers.txt b/docs/topics/db/managers.txt
index 3c0c3f3fb8..64d484e85d 100644
--- a/docs/topics/db/managers.txt
+++ b/docs/topics/db/managers.txt
@@ -242,8 +242,6 @@ the manager ``Person.people``.
 Creating ``Manager`` with ``QuerySet`` methods
 ----------------------------------------------
 
-.. versionadded:: 1.7
-
 In lieu of the above approach which requires duplicating methods on both the
 ``QuerySet`` and the ``Manager``, :meth:`QuerySet.as_manager()
 <django.db.models.query.QuerySet.as_manager>` can be used to create an instance
diff --git a/docs/topics/db/models.txt b/docs/topics/db/models.txt
index 754cdce13d..9decc9ebef 100644
--- a/docs/topics/db/models.txt
+++ b/docs/topics/db/models.txt
@@ -477,12 +477,6 @@ There are a few restrictions on the intermediate model:
   :attr:`symmetrical=False <ManyToManyField.symmetrical>` (see
   :ref:`the model field reference <manytomany-arguments>`).
 
-.. versionchanged:: 1.7
-
-    In Django 1.6 and earlier, intermediate models containing more than one
-    foreign key to any of the models involved in the many-to-many relationship
-    used to be prohibited.
-
 Now that you have set up your :class:`~django.db.models.ManyToManyField` to use
 your intermediary model (``Membership``, in this case), you're ready to start
 creating some many-to-many relationships. You do this by creating instances of
@@ -1303,41 +1297,9 @@ inheritance hierarchies as simple and straightforward as possible so that you
 won't have to struggle to work out where a particular piece of information is
 coming from.
 
-.. versionchanged:: 1.7
-
-Before Django 1.7, inheriting from multiple models that had an ``id`` primary
-key field did not raise an error, but could result in data loss. For example,
-consider these models (which no longer validate due to the clashing ``id``
-fields)::
-
-    class Article(models.Model):
-        headline = models.CharField(max_length=50)
-        body = models.TextField()
-
-    class Book(models.Model):
-        title = models.CharField(max_length=50)
-
-    class BookReview(Book, Article):
-        pass
-
-This snippet demonstrates how creating a child object overwrote the value of a
-previously created parent object::
-
-    >>> article = Article.objects.create(headline='Some piece of news.')
-    >>> review = BookReview.objects.create(
-    ...     headline='Review of Little Red Riding Hood.',
-    ...     title='Little Red Riding Hood')
-    >>>
-    >>> assert Article.objects.get(pk=article.pk).headline == article.headline
-    Traceback (most recent call last):
-      File "<console>", line 1, in <module>
-    AssertionError
-    >>> # the "Some piece of news." headline has been overwritten.
-    >>> Article.objects.get(pk=article.pk).headline
-    'Review of Little Red Riding Hood.'
-
-To properly use multiple inheritance, you can use an explicit
-:class:`~django.db.models.AutoField` in the base models::
+Note that inheriting from multiple models that have a common ``id`` primary
+key field will raise an error. To properly use multiple inheritance, you can
+use an explicit :class:`~django.db.models.AutoField` in the base models::
 
     class Article(models.Model):
         article_id = models.AutoField(primary_key=True)
diff --git a/docs/topics/db/queries.txt b/docs/topics/db/queries.txt
index 7aff43e9c7..c616d02b33 100644
--- a/docs/topics/db/queries.txt
+++ b/docs/topics/db/queries.txt
@@ -618,10 +618,6 @@ and with other ``F()`` objects. To find all the blog entries with more than
 
     >>> Entry.objects.filter(n_comments__gt=F('n_pingbacks') * 2)
 
-.. versionadded:: 1.7
-
-    The power operator ``**`` was added.
-
 To find all the entries where the rating of the entry is less than the
 sum of the pingback count and comment count, we would issue the
 query::
@@ -1149,8 +1145,6 @@ above example code would look like this::
 Using a custom reverse manager
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. versionadded:: 1.7
-
 By default the :class:`~django.db.models.fields.related.RelatedManager` used
 for reverse relations is a subclass of the :ref:`default manager <manager-names>`
 for that model. If you would like to specify a different manager for a given
diff --git a/docs/topics/db/sql.txt b/docs/topics/db/sql.txt
index a759ff50a7..0c382e811d 100644
--- a/docs/topics/db/sql.txt
+++ b/docs/topics/db/sql.txt
@@ -314,16 +314,6 @@ Also note that Django expects the ``"%s"`` placeholder, *not* the ``"?"``
 placeholder, which is used by the SQLite Python bindings. This is for the sake
 of consistency and sanity.
 
-.. versionchanged:: 1.7
-
-:pep:`249` does not state whether a cursor should be usable as a context
-manager. Prior to Python 2.7, a cursor was usable as a context manager due
-an unexpected behavior in magic method lookups (`Python ticket #9220`_).
-Django 1.7 explicitly added support to allow using a cursor as context
-manager.
-
-.. _`Python ticket #9220`: https://bugs.python.org/issue9220
-
 Using a cursor as a context manager::
 
     with connection.cursor() as c:
diff --git a/docs/topics/email.txt b/docs/topics/email.txt
index aabe66085e..841b08607b 100644
--- a/docs/topics/email.txt
+++ b/docs/topics/email.txt
@@ -74,10 +74,6 @@ are required.
 The return value will be the number of successfully delivered messages (which
 can be ``0`` or ``1`` since it can only send one message).
 
-.. versionadded:: 1.7
-
-    The ``html_message`` parameter was added.
-
 send_mass_mail()
 ================
 
@@ -333,17 +329,15 @@ The class has the following methods:
 
        message.attach('design.png', img_data, 'image/png')
 
-    .. versionchanged:: 1.7
+    If you specify a ``mimetype`` of ``message/rfc822``, it will also accept
+    :class:`django.core.mail.EmailMessage` and :py:class:`email.message.Message`.
 
-        If you specify a ``mimetype`` of ``message/rfc822``, it will also accept
-        :class:`django.core.mail.EmailMessage` and :py:class:`email.message.Message`.
+    In addition, ``message/rfc822`` attachments will no longer be
+    base64-encoded in violation of :rfc:`2046#section-5.2.1`, which can cause
+    issues with displaying the attachments in `Evolution`__ and `Thunderbird`__.
 
-        In addition, ``message/rfc822`` attachments will no longer be
-        base64-encoded in violation of :rfc:`2046#section-5.2.1`, which can cause
-        issues with displaying the attachments in `Evolution`__ and `Thunderbird`__.
-
-        __ https://bugzilla.gnome.org/show_bug.cgi?id=651197
-        __ https://bugzilla.mozilla.org/show_bug.cgi?id=333880
+    __ https://bugzilla.gnome.org/show_bug.cgi?id=651197
+    __ https://bugzilla.mozilla.org/show_bug.cgi?id=333880
 
 * ``attach_file()`` creates a new attachment using a file from your
   filesystem. Call it with the path of the file to attach and, optionally,
@@ -468,12 +462,8 @@ SMTP backend
 
         EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
 
-    .. versionadded:: 1.7
-
-        The ``timeout`` parameter was added. If unspecified, the default
-        ``timeout`` will be the one provided by
-        :func:`socket.getdefaulttimeout()`, which defaults to ``None`` (no
-        timeout).
+    If unspecified, the default ``timeout`` will be the one provided by
+    :func:`socket.getdefaulttimeout()`, which defaults to ``None`` (no timeout).
 
     .. versionchanged:: 1.8
 
diff --git a/docs/topics/forms/formsets.txt b/docs/topics/forms/formsets.txt
index a6e08ee749..5d8fd87875 100644
--- a/docs/topics/forms/formsets.txt
+++ b/docs/topics/forms/formsets.txt
@@ -343,8 +343,6 @@ excessive.
 ``validate_min``
 ~~~~~~~~~~~~~~~~
 
-.. versionadded:: 1.7
-
 If ``validate_min=True`` is passed to
 :func:`~django.forms.formsets.formset_factory`, validation will also check
 that the number of forms in the data set, minus those marked for
@@ -371,11 +369,6 @@ deletion, is greater than or equal to ``min_num``.
     >>> formset.non_form_errors()
     ['Please submit 3 or more forms.']
 
-.. versionchanged:: 1.7
-
-   The ``min_num`` and ``validate_min`` parameters were added to
-   :func:`~django.forms.formsets.formset_factory`.
-
 Dealing with ordering and deletion of forms
 -------------------------------------------
 
@@ -502,29 +495,15 @@ If you are using a :class:`ModelFormSet<django.forms.models.BaseModelFormSet>`,
 model instances for deleted forms will be deleted when you call
 ``formset.save()``.
 
-.. versionchanged:: 1.7
-
-    If you call ``formset.save(commit=False)``, objects will not be deleted
-    automatically.  You'll need to call ``delete()`` on each of the
-    :attr:`formset.deleted_objects
-    <django.forms.models.BaseModelFormSet.deleted_objects>` to actually delete
-    them::
-
-        >>> instances = formset.save(commit=False)
-        >>> for obj in formset.deleted_objects:
-        ...     obj.delete()
-
-    If you want to maintain backwards compatibility with Django 1.6 and earlier,
-    you can do something like this::
+If you call ``formset.save(commit=False)``, objects will not be deleted
+automatically.  You'll need to call ``delete()`` on each of the
+:attr:`formset.deleted_objects
+<django.forms.models.BaseModelFormSet.deleted_objects>` to actually delete
+them::
 
-        >>> try:
-        >>>     # For Django 1.7+
-        >>>     for obj in formset.deleted_objects:
-        >>>         obj.delete()
-        >>> except AssertionError:
-        >>>     # Django 1.6 and earlier already deletes the objects, trying to
-        >>>     # delete them a second time raises an AssertionError.
-        >>>     pass
+    >>> instances = formset.save(commit=False)
+    >>> for obj in formset.deleted_objects:
+    ...     obj.delete()
 
 On the other hand, if you are using a plain ``FormSet``, it's up to you to
 handle ``formset.deleted_forms``, perhaps in your formset's ``save()`` method,
diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt
index bfc066d251..c48680b60f 100644
--- a/docs/topics/forms/modelforms.txt
+++ b/docs/topics/forms/modelforms.txt
@@ -275,8 +275,6 @@ Error messages  defined on :attr:`model fields
 <validating-objects>` step and no corresponding error messages are defined at
 the form level.
 
-.. versionadded:: 1.7
-
 You can override the error messages from ``NON_FIELD_ERRORS`` raised by model
 validation by adding the :data:`~django.core.exceptions.NON_FIELD_ERRORS` key
 to the ``error_messages`` dictionary of the ``ModelForm``’s inner ``Meta`` class::
@@ -656,15 +654,11 @@ There are a couple of things to note, however.
   used. This means the child's ``Meta``, if it exists, otherwise the
   ``Meta`` of the first parent, etc.
 
-.. versionchanged:: 1.7
-
 * It's possible to inherit from both ``Form`` and ``ModelForm`` simultaneously,
   however, you must ensure that ``ModelForm`` appears first in the MRO. This is
   because these classes rely on different metaclasses and a class can only have
   one metaclass.
 
-.. versionadded:: 1.7
-
 * It's possible to declaratively remove a ``Field`` inherited from a parent class by
   setting the name to be ``None`` on the subclass.
 
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index 46c273726b..40faf1870a 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -95,11 +95,6 @@ session data be expunged from time to time, the ``cache`` backend is for you.
 If you use the ``cached_db`` session backend, you also need to follow the
 configuration instructions for the `using database-backed sessions`_.
 
-.. versionchanged:: 1.7
-
-    Before version 1.7, the ``cached_db`` backend always used the ``default``
-    cache rather than the :setting:`SESSION_CACHE_ALIAS`.
-
 Using file-based sessions
 -------------------------
 
diff --git a/docs/topics/http/shortcuts.txt b/docs/topics/http/shortcuts.txt
index f015786838..957f042d12 100644
--- a/docs/topics/http/shortcuts.txt
+++ b/docs/topics/http/shortcuts.txt
@@ -77,10 +77,6 @@ Optional arguments
        The ``current_app`` argument is deprecated. Instead you should set
        ``request.current_app``.
 
-.. versionchanged:: 1.7
-
-   The ``dirs`` parameter was added.
-
 .. deprecated:: 1.8
 
    The ``dirs`` parameter was deprecated.
@@ -167,10 +163,6 @@ Optional arguments
 
    The ``status`` parameter was added.
 
-.. versionchanged:: 1.7
-
-   The ``dirs`` parameter was added.
-
 .. deprecated:: 1.8
 
    The ``dirs`` parameter was deprecated.
@@ -223,10 +215,6 @@ This example is equivalent to::
    By default issues a temporary redirect; pass ``permanent=True`` to issue a
    permanent redirect.
 
-   .. versionchanged:: 1.7
-
-       The ability to use relative URLs was added.
-
 Examples
 --------
 
diff --git a/docs/topics/i18n/translation.txt b/docs/topics/i18n/translation.txt
index ad618c9d5a..7da54127cf 100644
--- a/docs/topics/i18n/translation.txt
+++ b/docs/topics/i18n/translation.txt
@@ -699,11 +699,6 @@ will result in the entry ``"First sentence. Second paragraph."`` in the PO file,
 compared to ``"\n  First sentence.\n  Second sentence.\n"``, if the ``trimmed``
 option had not been specified.
 
-.. versionchanged:: 1.7
-
-    The ``trimmed`` option was added.
-
-
 String literals passed to tags and filters
 ------------------------------------------
 
@@ -1275,16 +1270,13 @@ is configured correctly). It creates (or updates) a message file in the
 directory ``locale/LANG/LC_MESSAGES``. In the ``de`` example, the file will be
 ``locale/de/LC_MESSAGES/django.po``.
 
-.. versionchanged:: 1.7
-
-    When you run ``makemessages`` from the root directory of your project, the
-    extracted strings will be automatically distributed to the proper message
-    files. That is, a string extracted from a file of an app containing a
-    ``locale`` directory will go in a message file under that directory.
-    A string extracted from a file of an app without any ``locale`` directory
-    will either go in a message file under the directory listed first in
-    :setting:`LOCALE_PATHS` or will generate an error if :setting:`LOCALE_PATHS`
-    is empty.
+When you run ``makemessages`` from the root directory of your project, the
+extracted strings will be automatically distributed to the proper message files.
+That is, a string extracted from a file of an app containing a ``locale``
+directory will go in a message file under that directory. A string extracted
+from a file of an app without any ``locale`` directory will either go in a
+message file under the directory listed first in :setting:`LOCALE_PATHS` or
+will generate an error if :setting:`LOCALE_PATHS` is empty.
 
 By default :djadmin:`django-admin makemessages <makemessages>` examines every
 file that has the ``.html`` or ``.txt`` file extension. In case you want to
@@ -1627,14 +1619,10 @@ Language cookie
 A number of settings can be used to adjust language cookie options:
 
 * :setting:`LANGUAGE_COOKIE_NAME`
-
-.. versionadded:: 1.7
-
 * :setting:`LANGUAGE_COOKIE_AGE`
 * :setting:`LANGUAGE_COOKIE_DOMAIN`
 * :setting:`LANGUAGE_COOKIE_PATH`
 
-
 Implementation notes
 ====================
 
@@ -1716,11 +1704,6 @@ following this algorithm:
 * Failing that, it looks for the :data:`~django.utils.translation.LANGUAGE_SESSION_KEY`
   key in the current user's session.
 
-  .. versionchanged:: 1.7
-
-      In previous versions, the key was named ``django_language``, and the
-      ``LANGUAGE_SESSION_KEY`` constant did not exist.
-
 * Failing that, it looks for a cookie.
 
   The name of the cookie used is set by the :setting:`LANGUAGE_COOKIE_NAME`
diff --git a/docs/topics/logging.txt b/docs/topics/logging.txt
index 5dbd01c383..9318dbe4f4 100644
--- a/docs/topics/logging.txt
+++ b/docs/topics/logging.txt
@@ -498,8 +498,6 @@ specific logger following this example:
 ``django.db.backends.schema``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. versionadded:: 1.7
-
 Logs the SQL queries that are executed during schema changes to the database by
 the :doc:`migrations framework </topics/migrations>`. Note that it won't log the
 queries executed by :class:`~django.db.migrations.operations.RunPython`.
diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt
index 179dae823f..6896a34065 100644
--- a/docs/topics/migrations.txt
+++ b/docs/topics/migrations.txt
@@ -5,8 +5,6 @@ Migrations
 .. module:: django.db.migrations
    :synopsis: Schema migration support for Django models
 
-.. versionadded:: 1.7
-
 Migrations are Django's way of propagating changes you make to your models
 (adding a field, deleting a model, etc.) into your database schema. They're
 designed to be mostly automatic, but you'll need to know when to make
@@ -663,10 +661,6 @@ Django can serialize the following:
 - Any class reference (must be in module's top-level scope)
 - Anything with a custom ``deconstruct()`` method (:ref:`see below <custom-deconstruct-method>`)
 
-.. versionchanged:: 1.7.1
-
-    Support for serializing timezone-aware datetimes was added.
-
 Django can serialize the following on Python 3 only:
 
 - Unbound methods used from within the class body (see below)
diff --git a/docs/topics/serialization.txt b/docs/topics/serialization.txt
index 354aa9824d..6828eb0f62 100644
--- a/docs/topics/serialization.txt
+++ b/docs/topics/serialization.txt
@@ -405,8 +405,6 @@ into the primary key of an actual ``Person`` object.
     fields will be effectively unique, you can still use those fields
     as a natural key.
 
-.. versionadded:: 1.7
-
 Deserialization of objects with no primary key will always check whether the
 model's manager has a ``get_by_natural_key()`` method and if so, use it to
 populate the deserialized object's primary key.
diff --git a/docs/topics/signals.txt b/docs/topics/signals.txt
index 623e595daf..cc01a172ad 100644
--- a/docs/topics/signals.txt
+++ b/docs/topics/signals.txt
@@ -140,12 +140,6 @@ Now, our ``my_callback`` function will be called each time a request finishes.
     decorator, simply import the ``signals`` submodule inside
     :meth:`~django.apps.AppConfig.ready`.
 
-    .. versionchanged:: 1.7
-
-        Since :meth:`~django.apps.AppConfig.ready` didn't exist in previous
-        versions of Django, signal registration usually happened in the
-        ``models`` module.
-
 .. note::
 
     The :meth:`~django.apps.AppConfig.ready` method may be executed more than
diff --git a/docs/topics/templates.txt b/docs/topics/templates.txt
index 30e1b9b011..6be5d6165d 100644
--- a/docs/topics/templates.txt
+++ b/docs/topics/templates.txt
@@ -115,10 +115,6 @@ The ``django.template.loader`` module defines two functions to load templates.
     If you want to restrict the search to a particular template engine, pass
     the engine's :setting:`NAME <TEMPLATES-NAME>` in the ``using`` argument.
 
-    .. versionchanged:: 1.7
-
-       The ``dirs`` parameter was added.
-
     .. deprecated:: 1.8
 
        The ``dirs`` parameter was deprecated.
@@ -138,10 +134,6 @@ The ``django.template.loader`` module defines two functions to load templates.
     list of template names. It tries each name in order and returns the first
     template that exists.
 
-    .. versionchanged:: 1.7
-
-       The ``dirs`` parameter was added.
-
     .. deprecated:: 1.8
 
        The ``dirs`` parameter was deprecated.
diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt
index c995d5ec5c..3ca8ed88cf 100644
--- a/docs/topics/testing/advanced.txt
+++ b/docs/topics/testing/advanced.txt
@@ -414,16 +414,12 @@ Attributes
 
 .. attribute:: DiscoverRunner.test_suite
 
-    .. versionadded:: 1.7
-
     The class used to build the test suite. By default it is set to
     ``unittest.TestSuite``. This can be overridden if you wish to implement
     different logic for collecting tests.
 
 .. attribute:: DiscoverRunner.test_runner
 
-    .. versionadded:: 1.7
-
     This is the class of the low-level test runner which is used to execute
     the individual tests and format the results. By default it is set to
     ``unittest.TextTestRunner``. Despite the unfortunate similarity in
@@ -594,11 +590,9 @@ can be useful during testing.
     ``False`` to speed up creation time if you don't have any test classes
     with :ref:`serialized_rollback=True <test-case-serialized-rollback>`.
 
-    .. versionadded:: 1.7.1
-
-        If you are using the default test runner, you can control this with the
-        the :setting:`SERIALIZE <TEST_SERIALIZE>` entry in the
-        :setting:`TEST <DATABASE-TEST>` dictionary
+    If you are using the default test runner, you can control this with the
+    the :setting:`SERIALIZE <TEST_SERIALIZE>` entry in the :setting:`TEST
+    <DATABASE-TEST>` dictionary.
 
     ``keepdb`` determines if the test run should use an existing
     database, or create a new one. If ``True``, the existing
@@ -612,10 +606,6 @@ can be useful during testing.
     :setting:`NAME` in :setting:`DATABASES` to match the name of the test
     database.
 
-    .. versionchanged:: 1.7
-
-        The ``serialize`` argument was added.
-
     .. versionchanged:: 1.8
 
         The ``keepdb`` argument was added.
diff --git a/docs/topics/testing/overview.txt b/docs/topics/testing/overview.txt
index 57bdfaa0ca..ac1c4b550e 100644
--- a/docs/topics/testing/overview.txt
+++ b/docs/topics/testing/overview.txt
@@ -152,10 +152,8 @@ entirely!). If you want to use a different database name, specify
 :setting:`NAME <TEST_NAME>` in the :setting:`TEST <DATABASE-TEST>`
 dictionary for any given database in :setting:`DATABASES`.
 
-.. versionchanged:: 1.7
-
-    On PostgreSQL, :setting:`USER` will also need read access to the built-in
-    ``postgres`` database.
+On PostgreSQL, :setting:`USER` will also need read access to the built-in
+``postgres`` database.
 
 Aside from using a separate database, the test runner will otherwise
 use all of the same database settings you have in your settings file:
@@ -175,12 +173,6 @@ If using a SQLite in-memory database with Python 3.4+ and SQLite 3.7.13+,
 `shared cache <https://www.sqlite.org/sharedcache.html>`_ will be enabled, so
 you can write tests with ability to share the database between threads.
 
-.. versionchanged:: 1.7
-
-   The different options in the :setting:`TEST <DATABASE-TEST>` database
-   setting used to be separate options in the database settings dictionary,
-   prefixed with ``TEST_``.
-
 .. versionadded:: 1.8
 
     The ability to use SQLite with a shared cache as described above was added.
@@ -194,10 +186,8 @@ you can write tests with ability to share the database between threads.
     your tests. *It is a bad idea to have such import-time database queries in
     your code* anyway - rewrite your code so that it doesn't do this.
 
-    .. versionadded:: 1.7
-
-        This also applies to customized implementations of
-        :meth:`~django.apps.AppConfig.ready()`.
+    This also applies to customized implementations of
+    :meth:`~django.apps.AppConfig.ready()`.
 
 .. seealso::
 
diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt
index 9d3ae456fd..a8637bf381 100644
--- a/docs/topics/testing/tools.txt
+++ b/docs/topics/testing/tools.txt
@@ -130,10 +130,6 @@ Use the ``django.test.Client`` class to make requests.
 
     .. method:: Client.get(path, data=None, follow=False, secure=False, **extra)
 
-        .. versionadded:: 1.7
-
-            The ``secure`` argument was added.
-
         Makes a GET request on the provided ``path`` and returns a ``Response``
         object, which is documented below.
 
@@ -435,8 +431,6 @@ Specifically, a ``Response`` object has the following attributes:
 
     .. attribute:: wsgi_request
 
-        .. versionadded:: 1.7
-
         The ``WSGIRequest`` instance generated by the test handler that
         generated the response.
 
@@ -845,25 +839,15 @@ out the `full reference`_ for more details.
 .. _full reference: http://selenium-python.readthedocs.org/en/latest/api.html
 .. _Firefox: http://www.mozilla.com/firefox/
 
-.. versionchanged:: 1.7
-
-    Before Django 1.7 ``LiveServerTestCase`` used to rely on the
-    :doc:`staticfiles contrib app </howto/static-files/index>` to get the
-    static assets of the application(s) under test transparently served at their
-    expected locations during the execution of these tests.
-
-    In Django 1.7 this dependency of core functionality on a ``contrib``
-    application has been removed, because of which ``LiveServerTestCase``
-    ability in this respect has been retrofitted to simply publish the contents
-    of the file system under :setting:`STATIC_ROOT` at the :setting:`STATIC_URL`
-    URL.
+.. tip::
 
-    If you use the ``staticfiles`` app in your project and need to perform live
-    testing then you might want to consider using the
+    If you use the :mod:`~django.contrib.staticfiles` app in your project and
+    need to perform live testing, then you might want to use the
     :class:`~django.contrib.staticfiles.testing.StaticLiveServerTestCase`
-    subclass shipped with it instead because it's the one that implements the
-    original behavior now. See :ref:`the relevant documentation
-    <staticfiles-testing-support>` for more details.
+    subclass which transparently serves all the assets during execution of
+    its tests in a way very similar to what we get at development time with
+    ``DEBUG=True``, i.e. without having to collect them using
+    :djadmin:`collectstatic`.
 
 .. note::
 
@@ -1135,8 +1119,6 @@ in the ``with`` block and reset its value to the previous state afterwards.
 
 .. method:: SimpleTestCase.modify_settings()
 
-.. versionadded:: 1.7
-
 It can prove unwieldy to redefine settings that contain a list of values. In
 practice, adding or removing values is often sufficient. The
 :meth:`~django.test.SimpleTestCase.modify_settings` context manager makes it
@@ -1189,14 +1171,8 @@ The decorator can also be applied to :class:`~django.test.TestCase` classes::
             response = self.client.get('/sekrit/')
             self.assertRedirects(response, '/other/login/?next=/sekrit/')
 
-.. versionchanged:: 1.7
-
-    Previously, ``override_settings`` was imported from ``django.test.utils``.
-
 .. function:: modify_settings
 
-.. versionadded:: 1.7
-
 Likewise, Django provides the :func:`~django.test.modify_settings`
 decorator::
 
@@ -1265,11 +1241,6 @@ have been overridden, like this::
         del settings.LOGIN_URL
         ...
 
-.. versionchanged:: 1.7
-
-    Previously, you could only simulate the deletion of a setting which was
-    explicitly overridden.
-
 When overriding settings, make sure to handle the cases in which your app's
 code uses a cache or similar feature that retains state even if the setting is
 changed. Django provides the :data:`django.test.signals.setting_changed`
@@ -1445,14 +1416,10 @@ your test suite.
     host (for example, initializing the test client with
     ``Client(HTTP_HOST="testhost")``.
 
-    .. versionadded:: 1.7
-
     If ``fetch_redirect_response`` is ``False``, the final page won't be
     loaded. Since the test client can't fetch externals URLs, this is
     particularly useful if ``expected_url`` isn't part of your Django app.
 
-    .. versionadded:: 1.7
-
     Scheme is handled correctly when making comparisons between two URLs. If
     there isn't any scheme specified in the location where we are redirected to,
     the original request's scheme is used. If present, the scheme in
@@ -1564,11 +1531,6 @@ your test suite.
 
     Output in case of error can be customized with the ``msg`` argument.
 
-    .. versionchanged:: 1.7
-
-        The method now accepts a ``msg`` parameter to allow customization of
-        error message
-
 .. method:: TransactionTestCase.assertNumQueries(num, func, *args, **kwargs)
 
     Asserts that when ``func`` is called with ``*args`` and ``**kwargs`` that
@@ -1705,10 +1667,6 @@ it would under MySQL with MyISAM tables)::
         def test_transaction_behavior(self):
             # ... conditional test code
 
-.. versionchanged:: 1.7
-
-    ``skipIfDBFeature`` can now be used to decorate a ``TestCase`` class.
-
 .. versionchanged:: 1.8
 
     ``skipIfDBFeature`` can accept multiple feature strings.
@@ -1727,10 +1685,6 @@ under MySQL with MyISAM tables)::
         def test_transaction_behavior(self):
             # ... conditional test code
 
-.. versionchanged:: 1.7
-
-    ``skipUnlessDBFeature`` can now be used to decorate a ``TestCase`` class.
-
 .. versionchanged:: 1.8
 
     ``skipUnlessDBFeature`` can accept multiple feature strings.