Removed versionadded/changed annotations for 1.8.

24 files changed, 16 insertions, 275 deletions

diff --git a/docs/topics/auth/customizing.txt b/docs/topics/auth/customizing.txt
index 8b4da2048e..01d52d9262 100644
--- a/docs/topics/auth/customizing.txt
+++ b/docs/topics/auth/customizing.txt
@@ -180,13 +180,10 @@ The permissions given to the user will be the superset of all permissions
 returned by all backends. That is, Django grants a permission to a user that
 any one backend grants.
 
-.. versionadded:: 1.8
-
-    If a backend raises a :class:`~django.core.exceptions.PermissionDenied`
-    exception in :meth:`~django.contrib.auth.models.User.has_perm()` or
-    :meth:`~django.contrib.auth.models.User.has_module_perms()`,
-    the authorization will immediately fail and Django
-    won't check the backends that follow.
+If a backend raises a :class:`~django.core.exceptions.PermissionDenied`
+exception in :meth:`~django.contrib.auth.models.User.has_perm()` or
+:meth:`~django.contrib.auth.models.User.has_module_perms()`, the authorization
+will immediately fail and Django won't check the backends that follow.
 
 The simple backend above could implement permissions for the magic admin
 fairly simply::
@@ -494,11 +491,6 @@ Django expects your custom User model to meet some minimum requirements.
    what these two methods return - if you want, they can return exactly
    the same value.
 
-.. versionchanged:: 1.8
-
-    Older versions of Django required your model to have an integer primary
-    key as well.
-
 The easiest way to construct a compliant custom User model is to inherit from
 :class:`~django.contrib.auth.models.AbstractBaseUser`.
 :class:`~django.contrib.auth.models.AbstractBaseUser` provides the core
@@ -526,8 +518,6 @@ password resets. You must then provide some key implementation details:
                 ...
                 USERNAME_FIELD = 'identifier'
 
-        .. versionadded:: 1.8
-
         :attr:`USERNAME_FIELD` now supports
         :class:`~django.db.models.ForeignKey`\s. Since there is no way to pass
         model instances during the :djadmin:`createsuperuser` prompt, expect the
@@ -562,8 +552,6 @@ password resets. You must then provide some key implementation details:
             ``User`` model, but should *not* contain the ``USERNAME_FIELD`` or
             ``password`` as these fields will always be prompted for.
 
-        .. versionadded:: 1.8
-
         :attr:`REQUIRED_FIELDS` now supports
         :class:`~django.db.models.ForeignKey`\s. Since there is no way to pass
         model instances during the :djadmin:`createsuperuser` prompt, expect the
diff --git a/docs/topics/auth/default.txt b/docs/topics/auth/default.txt
index 9eeae69ed2..9ae5a50cd5 100644
--- a/docs/topics/auth/default.txt
+++ b/docs/topics/auth/default.txt
@@ -1516,8 +1516,6 @@ provides several built-in forms located in :mod:`django.contrib.auth.forms`:
 
     .. method:: send_email(subject_template_name, email_template_name, context, from_email, to_email, html_email_template_name=None)
 
-        .. versionadded:: 1.8
-
         Uses the arguments to send an ``EmailMultiAlternatives``.
         Can be overridden to customize how the email is sent to the user.
 
diff --git a/docs/topics/checks.txt b/docs/topics/checks.txt
index 978bca7f5b..5521c9cb8d 100644
--- a/docs/topics/checks.txt
+++ b/docs/topics/checks.txt
@@ -99,8 +99,6 @@ make the following call::
         # ... perform compatibility checks and collect errors
         return errors
 
-.. versionadded:: 1.8
-
 You can register "deployment checks" that are only relevant to a production
 settings file like this::
 
@@ -121,10 +119,6 @@ The code below is equivalent to the code above::
         ...
     register(my_check, Tags.security, deploy=True)
 
-.. versionchanged:: 1.8
-
-    The ability to use register as a function was added.
-
 .. _field-checking:
 
 Field, Model, and Manager checks
diff --git a/docs/topics/class-based-views/generic-editing.txt b/docs/topics/class-based-views/generic-editing.txt
index 0ada8db42a..7b3b5083cc 100644
--- a/docs/topics/class-based-views/generic-editing.txt
+++ b/docs/topics/class-based-views/generic-editing.txt
@@ -143,16 +143,6 @@ If you specify both the :attr:`~django.views.generic.edit.ModelFormMixin.fields`
 and :attr:`~django.views.generic.edit.FormMixin.form_class` attributes, an
 :exc:`~django.core.exceptions.ImproperlyConfigured` exception will be raised.
 
-.. versionchanged:: 1.8
-
-    Omitting the ``fields`` attribute was previously allowed and resulted in a
-    form with all of the model's fields.
-
-.. versionchanged:: 1.8
-
-    Previously if both ``fields`` and ``form_class`` were specified,
-    ``fields`` was silently ignored.
-
 Finally, we hook these new views into the URLconf:
 
 .. snippet::
diff --git a/docs/topics/conditional-view-processing.txt b/docs/topics/conditional-view-processing.txt
index 77080266de..ed319474fa 100644
--- a/docs/topics/conditional-view-processing.txt
+++ b/docs/topics/conditional-view-processing.txt
@@ -33,11 +33,6 @@ returned.
 When you need more fine-grained control you may use per-view conditional
 processing functions.
 
-.. versionchanged:: 1.8
-
-    Support for the ``If-unmodified-since`` header was added to conditional
-    view processing.
-
 .. _conditional-decorators:
 
 The ``condition`` decorator
diff --git a/docs/topics/db/examples/many_to_one.txt b/docs/topics/db/examples/many_to_one.txt
index efa5c37f3b..93cc3f093f 100644
--- a/docs/topics/db/examples/many_to_one.txt
+++ b/docs/topics/db/examples/many_to_one.txt
@@ -60,13 +60,6 @@ raises ``ValueError``::
     ...
     ValueError: save() prohibited to prevent data loss due to unsaved related object 'reporter'.
 
-.. versionchanged:: 1.8.4
-
-    Previously, saving an object with unsaved related objects did not raise an
-    error and could result in silent data loss. In 1.8-1.8.3, unsaved model
-    instances couldn't be assigned to related fields, but this restriction was
-    removed to allow easier usage of in-memory models.
-
 Article objects have access to their related Reporter objects::
 
     >>> r = a.reporter
diff --git a/docs/topics/db/examples/one_to_one.txt b/docs/topics/db/examples/one_to_one.txt
index 8eb003b167..dbf46fc079 100644
--- a/docs/topics/db/examples/one_to_one.txt
+++ b/docs/topics/db/examples/one_to_one.txt
@@ -101,13 +101,6 @@ raises ``ValueError``::
     ...
     ValueError: save() prohibited to prevent data loss due to unsaved related object 'place'.
 
-.. versionchanged:: 1.8.4
-
-    Previously, saving an object with unsaved related objects did not raise an
-    error and could result in silent data loss. In 1.8-1.8.3, unsaved model
-    instances couldn't be assigned to related fields, but this restriction was
-    removed to allow easier usage of in-memory models.
-
 Restaurant.objects.all() just returns the Restaurants, not the Places.  Note
 that there are two restaurants - Ace Hardware the Restaurant was created in the
 call to r.place = p2::
diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt
index ad4e027ef5..618d0cc074 100644
--- a/docs/topics/db/transactions.txt
+++ b/docs/topics/db/transactions.txt
@@ -202,11 +202,6 @@ Django provides a single API to control database transactions.
     You may use ``atomic`` when autocommit is turned off. It will only use
     savepoints, even for the outermost block.
 
-    .. versionchanged:: 1.8.5
-
-        Previously the outermost atomic block couldn't be declared with
-        ``savepoint=False`` when autocommit was turned off.
-
 .. admonition:: Performance considerations
 
     Open transactions have a performance cost for your database server. To
diff --git a/docs/topics/email.txt b/docs/topics/email.txt
index 16db4976d6..15f82a3a8e 100644
--- a/docs/topics/email.txt
+++ b/docs/topics/email.txt
@@ -277,10 +277,6 @@ All parameters are optional and can be set at any time prior to calling the
 * ``reply_to``: A list or tuple of recipient addresses used in the "Reply-To"
   header when sending the email.
 
-.. versionchanged:: 1.8
-
-    The ``reply_to`` parameter was added.
-
 For example::
 
     email = EmailMessage('Hello', 'Body goes here', 'from@example.com',
@@ -412,10 +408,6 @@ It can also be used as a context manager, which will automatically call
         mail.EmailMessage(subject2, body2, from2, [to2],
                           connection=connection).send()
 
-.. versionadded:: 1.8
-
-    The context manager protocol was added.
-
 Obtaining an instance of an email backend
 -----------------------------------------
 
@@ -472,12 +464,6 @@ SMTP backend
     If unspecified, the default ``timeout`` will be the one provided by
     :func:`socket.getdefaulttimeout()`, which defaults to ``None`` (no timeout).
 
-    .. versionchanged:: 1.8
-
-        The ``ssl_keyfile``, and ``ssl_certfile`` parameters and corresponding
-        settings were added. The ability to customize ``timeout`` using
-        a setting (:setting:`EMAIL_TIMEOUT`) was added.
-
 .. _topic-email-console-backend:
 
 Console backend
diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt
index c9cce5121f..27a5314347 100644
--- a/docs/topics/forms/index.txt
+++ b/docs/topics/forms/index.txt
@@ -615,10 +615,6 @@ errors. For example, ``{{ form.non_field_errors }}`` would look like:
         <li>Generic validation error</li>
     </ul>
 
-.. versionchanged:: 1.8
-
-    The ``nonfield`` class as described in the example above was added.
-
 See :doc:`/ref/forms/api` for more on errors, styling, and working with form
 attributes in templates.
 
diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt
index e9898c6fff..6370636d4e 100644
--- a/docs/topics/forms/modelforms.txt
+++ b/docs/topics/forms/modelforms.txt
@@ -436,12 +436,6 @@ In addition, Django applies the following rule: if you set ``editable=False`` on
 the model field, *any* form created from the model via ``ModelForm`` will not
 include that field.
 
-.. versionchanged:: 1.8
-
-    In older versions, omitting both ``fields`` and ``exclude`` resulted in
-    a form with all the model's fields. Doing this now raises an
-    :exc:`~django.core.exceptions.ImproperlyConfigured` exception.
-
 .. note::
 
     Any fields not included in a form by the above logic
@@ -745,12 +739,6 @@ exclude::
 
     >>> AuthorFormSet = modelformset_factory(Author, exclude=('birth_date',))
 
-.. versionchanged:: 1.8
-
-    In older versions, omitting both ``fields`` and ``exclude`` resulted in
-    a formset with all the model's fields. Doing this now raises an
-    :exc:`~django.core.exceptions.ImproperlyConfigured` exception.
-
 This will create a formset that is capable of working with the data associated
 with the ``Author`` model. It works just like a regular formset::
 
diff --git a/docs/topics/http/middleware.txt b/docs/topics/http/middleware.txt
index c9812268a0..7ffaa9fc32 100644
--- a/docs/topics/http/middleware.txt
+++ b/docs/topics/http/middleware.txt
@@ -273,11 +273,6 @@ that piece of middleware from the middleware process and a debug message will
 be logged to the ``django.request`` logger when :setting:`DEBUG` is set to
 ``True``.
 
-.. versionchanged:: 1.8
-
-    Previously, :exc:`~django.core.exceptions.MiddlewareNotUsed` exceptions
-    weren't logged.
-
 Guidelines
 ----------
 
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index da9e5ef567..6c0182ef33 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -226,12 +226,6 @@ You can edit it multiple times.
       can't be accessed again from the user's browser (for example, the
       :func:`django.contrib.auth.logout()` function calls it).
 
-      .. versionchanged:: 1.8
-
-          Deletion of the session cookie is a behavior new in Django 1.8.
-          Previously, the behavior was to regenerate the session key value that
-          was sent back to the user in the cookie.
-
     .. method:: set_test_cookie()
 
       Sets a test cookie to determine whether the user's browser supports
diff --git a/docs/topics/http/shortcuts.txt b/docs/topics/http/shortcuts.txt
index 4ed7159de6..1635a4be01 100644
--- a/docs/topics/http/shortcuts.txt
+++ b/docs/topics/http/shortcuts.txt
@@ -56,10 +56,6 @@ Optional arguments
     The :setting:`NAME <TEMPLATES-NAME>` of a template engine to use for
     loading the template.
 
-.. versionchanged:: 1.8
-
-    The ``using`` parameter was added.
-
 Example
 -------
 
@@ -121,10 +117,6 @@ Optional arguments
     The :setting:`NAME <TEMPLATES-NAME>` of a template engine to use for
     loading the template.
 
-.. versionchanged:: 1.8
-
-   The ``status`` and ``using`` parameters were added.
-
 Example
 -------
 
diff --git a/docs/topics/i18n/formatting.txt b/docs/topics/i18n/formatting.txt
index 62e4cc9ede..8f04d65c38 100644
--- a/docs/topics/i18n/formatting.txt
+++ b/docs/topics/i18n/formatting.txt
@@ -154,12 +154,6 @@ Django provides format definitions for many locales, but sometimes you might
 want to create your own, because a format files doesn't exist for your locale,
 or because you want to overwrite some of the values.
 
-
-.. versionchanged:: 1.8
-
-    The ability to specify :setting:`FORMAT_MODULE_PATH` as a list was added.
-    Previously, only a single string value was supported.
-
 To use custom formats, specify the path where you'll place format files
 first. To do that, just set your :setting:`FORMAT_MODULE_PATH` setting to
 the package where format files will exist, for instance::
diff --git a/docs/topics/i18n/translation.txt b/docs/topics/i18n/translation.txt
index d78862c82c..82d0e54358 100644
--- a/docs/topics/i18n/translation.txt
+++ b/docs/topics/i18n/translation.txt
@@ -872,10 +872,6 @@ If you enable the ``django.template.context_processors.i18n`` context processor
 then each ``RequestContext`` will have access to ``LANGUAGES``,
 ``LANGUAGE_CODE``, and ``LANGUAGE_BIDI`` as defined above.
 
-.. versionchanged:: 1.8
-
-    The ``i18n`` context processor is not enabled by default for new projects.
-
 .. templatetag:: get_language_info
 
 ``get_language_info``
diff --git a/docs/topics/logging.txt b/docs/topics/logging.txt
index 3a8b80a0a5..2e8da1db4e 100644
--- a/docs/topics/logging.txt
+++ b/docs/topics/logging.txt
@@ -623,8 +623,6 @@ Python logging module.
 
     .. method:: send_mail(subject, message, *args, **kwargs)
 
-        .. versionadded:: 1.8
-
         Sends emails to admin users. To customize this behavior, you can
         subclass the :class:`~django.utils.log.AdminEmailHandler` class and
         override this method.
diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt
index 57b6c3216a..546c1a9807 100644
--- a/docs/topics/migrations.txt
+++ b/docs/topics/migrations.txt
@@ -140,8 +140,6 @@ developers (or your production servers) check out the code, they'll
 get both the changes to your models and the accompanying migration at the
 same time.
 
-.. versionadded:: 1.8
-
 If you want to give the migration(s) a meaningful name instead of a generated
 one, you can use the :djadminopt:`--name` option::
 
@@ -251,8 +249,6 @@ argument, please create a keyword argument and add something like
 Model managers
 ~~~~~~~~~~~~~~
 
-.. versionadded:: 1.8
-
 You can optionally serialize managers into migrations and have them available
 in :class:`~django.db.migrations.operations.RunPython` operations. This is done
 by defining a ``use_in_migrations`` attribute on the manager class::
@@ -333,12 +329,6 @@ Note that this only works given two things:
   that your database doesn't match your models, you'll just get errors when
   migrations try to modify those tables.
 
-.. versionchanged:: 1.8
-
-    The ``--fake-initial`` flag to :djadmin:`migrate` was added. Previously,
-    Django would always automatically fake-apply initial migrations if it
-    detected that the tables exist.
-
 .. _historical-models:
 
 Historical models
@@ -380,8 +370,6 @@ can opt to move them into a superclass.
 Considerations when removing model fields
 -----------------------------------------
 
-.. versionadded:: 1.8
-
 Similar to the "references to historical functions" considerations described in
 the previous section, removing custom model fields from your project or
 third-party app will cause a problem if they are referenced in old migrations.
@@ -781,48 +769,6 @@ should run unchanged on Django X.Y+1. The migrations system does not promise
 forwards-compatibility, however. New features may be added, and migration files
 generated with newer versions of Django may not work on older versions.
 
-.. _upgrading-from-south:
-
-Upgrading from South
---------------------
-
-If you already have pre-existing migrations created with
-`South <http://south.aeracode.org>`_, then the upgrade process to use
-``django.db.migrations`` is quite simple:
-
-* Ensure all installs are fully up-to-date with their migrations.
-* Remove ``'south'`` from :setting:`INSTALLED_APPS`.
-* Delete all your (numbered) migration files, but not the directory or
-  ``__init__.py`` - make sure you remove the ``.pyc`` files too.
-* Run ``python manage.py makemigrations``. Django should see the empty
-  migration directories and make new initial migrations in the new format.
-* Run ``python manage.py migrate --fake-initial``. Django will see that the
-  tables for the initial migrations already exist and mark them as applied
-  without running them. (Django won't check that the table schema match your
-  models, just that the right table names exist).
-
-.. versionchanged:: 1.8
-
-    The :djadminopt:`--fake-initial` flag was added to :djadmin:`migrate`;
-    previously, initial migrations were always automatically fake-applied if
-    existing tables were detected.
-
-Libraries/Third-party Apps
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If you are a library or app maintainer, and wish to support both South migrations
-(for Django 1.6 and below) and Django migrations (for 1.7 and above) you should
-keep two parallel migration sets in your app, one in each format.
-
-To aid in this, South 1.0 will automatically look for South-format migrations
-in a ``south_migrations`` directory first, before looking in ``migrations``,
-meaning that users' projects will transparently use the correct set as long
-as you put your South migrations in the ``south_migrations`` directory and
-your Django migrations in the ``migrations`` directory.
-
-More information is available in the
-`South 1.0 release notes <http://south.readthedocs.org/en/latest/releasenotes/1.0.html#library-migration-path>`_.
-
 .. seealso::
 
     :doc:`The Migrations Operations Reference </ref/migration-operations>`
diff --git a/docs/topics/signals.txt b/docs/topics/signals.txt
index fbc2409570..71b8213dd9 100644
--- a/docs/topics/signals.txt
+++ b/docs/topics/signals.txt
@@ -261,10 +261,8 @@ be notified of a signal in the face of an error.
 and ensures all receivers are notified of the signal. If an error occurs, the
 error instance is returned in the tuple pair for the receiver that raised the error.
 
-.. versionadded:: 1.8
-
-    The tracebacks are present on the ``__traceback__`` attribute
-    of the errors returned when calling ``send_robust()``.
+The tracebacks are present on the ``__traceback__`` attribute of the errors
+returned when calling ``send_robust()``.
 
 Disconnecting signals
 =====================
@@ -278,10 +276,6 @@ arguments are as described in :meth:`.Signal.connect`. The method returns
 The ``receiver`` argument indicates the registered receiver to disconnect. It
 may be ``None`` if ``dispatch_uid`` is used to identify the receiver.
 
-.. versionchanged:: 1.8
-
-    The boolean return value was added.
-
 .. deprecated:: 1.9
 
     The ``weak`` argument is deprecated as it has no effect. It will be removed
diff --git a/docs/topics/signing.txt b/docs/topics/signing.txt
index 18d963c41b..9d3b76a205 100644
--- a/docs/topics/signing.txt
+++ b/docs/topics/signing.txt
@@ -142,10 +142,6 @@ created within a specified period of time::
         otherwise raises ``SignatureExpired``. The ``max_age`` parameter can
         accept an integer or a :py:class:`datetime.timedelta` object.
 
-        .. versionchanged:: 1.8
-
-            Previously, the ``max_age`` parameter only accepted an integer.
-
 Protecting complex data structures
 ----------------------------------
 
diff --git a/docs/topics/templates.txt b/docs/topics/templates.txt
index af165b7052..f0abccc835 100644
--- a/docs/topics/templates.txt
+++ b/docs/topics/templates.txt
@@ -41,11 +41,6 @@ namespace.
 Support for template engines
 ============================
 
-.. versionadded:: 1.8
-
-    Support for multiple template engines and the :setting:`TEMPLATES` setting
-    were added in Django 1.8.
-
 Configuration
 -------------
 
@@ -115,30 +110,12 @@ 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.8
-
-       The ``using`` parameter was added.
-
-    .. versionchanged:: 1.8
-
-        ``get_template()`` returns a backend-dependent ``Template`` instead
-        of a :class:`django.template.Template`.
-
 .. function:: select_template(template_name_list, using=None)
 
     ``select_template()`` is just like ``get_template()``, except it takes a
     list of template names. It tries each name in order and returns the first
     template that exists.
 
-    .. versionchanged:: 1.8
-
-       The ``using`` parameter was added.
-
-    .. versionchanged:: 1.8
-
-        ``select_template()`` returns a backend-dependent ``Template`` instead
-        of a :class:`django.template.Template`.
-
 .. currentmodule:: django.template
 
 If loading a template fails, the following two exceptions, defined in
@@ -279,10 +256,6 @@ templates, Django provides a shortcut function which automates the process.
         An optional :class:`~django.http.HttpRequest` that will be available
         during the template's rendering process.
 
-        .. versionadded:: 1.8
-
-            The ``request`` argument was added.
-
 See also the :func:`~django.shortcuts.render()` and
 :func:`~django.shortcuts.render_to_response()` shortcuts, which call
 :func:`render_to_string()` and feed the result into an
diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt
index f2a2b103fc..e230c2624d 100644
--- a/docs/topics/testing/advanced.txt
+++ b/docs/topics/testing/advanced.txt
@@ -415,10 +415,6 @@ execute and tear down the test suite.
     custom arguments by calling ``parser.add_argument()`` inside the method, so
     that the :djadmin:`test` command will be able to use those arguments.
 
-    .. versionchanged:: 1.8
-
-        The ``keepdb``, ``reverse``, and ``debug_sql`` arguments were added.
-
 Attributes
 ~~~~~~~~~~
 
@@ -463,8 +459,6 @@ Methods
 
 .. classmethod:: DiscoverRunner.add_arguments(parser)
 
-    .. versionadded:: 1.8
-
     Override this class method to add custom arguments accepted by the
     :djadmin:`test` management command. See
     :py:meth:`argparse.ArgumentParser.add_argument()` for details about adding
@@ -604,10 +598,6 @@ can be useful during testing.
     :setting:`NAME` in :setting:`DATABASES` to match the name of the test
     database.
 
-    .. versionchanged:: 1.8
-
-        The ``keepdb`` argument was added.
-
 .. function:: destroy_test_db(old_database_name, verbosity=1, keepdb=False)
 
     Destroys the database whose name is the value of :setting:`NAME` in
@@ -620,10 +610,6 @@ can be useful during testing.
     If the ``keepdb`` argument is ``True``, then the connection to the
     database will be closed, but the database will not be destroyed.
 
-    .. versionchanged:: 1.8
-
-        The ``keepdb`` argument was added.
-
 .. _topics-testing-code-coverage:
 
 Integration with coverage.py
diff --git a/docs/topics/testing/overview.txt b/docs/topics/testing/overview.txt
index fc18eb0e4a..06e6172724 100644
--- a/docs/topics/testing/overview.txt
+++ b/docs/topics/testing/overview.txt
@@ -135,13 +135,10 @@ Tests that require a database (namely, model tests) will not use your "real"
 Regardless of whether the tests pass or fail, the test databases are destroyed
 when all the tests have been executed.
 
-.. versionadded:: 1.8
-
-   You can prevent the test databases from being destroyed by adding the
-   :djadminopt:`--keepdb` flag to the test command. This will preserve the test
-   database between runs. If the database does not exist, it will first
-   be created. Any migrations will also be applied in order to keep it
-   up to date.
+You can prevent the test databases from being destroyed by adding the
+:djadminopt:`--keepdb` flag to the test command. This will preserve the test
+database between runs. If the database does not exist, it will first be
+created. Any migrations will also be applied in order to keep it p to date.
 
 By default the test databases get their names by prepending ``test_``
 to the value of the :setting:`NAME` settings for the databases
@@ -173,10 +170,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.
 
-.. versionadded:: 1.8
-
-    The ability to use SQLite with a shared cache as described above was added.
-
 .. admonition:: Finding data from your production database when running tests?
 
     If your code attempts to access the database when its modules are compiled,
@@ -218,11 +211,9 @@ the Django test runner reorders tests in the following way:
     database by a given :class:`~django.test.TransactionTestCase` test, they
     must be updated to be able to run independently.
 
-.. versionadded:: 1.8
-
-    You may reverse the execution order inside groups by passing
-    :djadminopt:`--reverse` to the test command. This can help with ensuring
-    your tests are independent from each other.
+You may reverse the execution order inside groups by passing
+:djadminopt:`--reverse` to the test command. This can help with ensuring your
+tests are independent from each other.
 
 .. _test-case-serialized-rollback:
 
diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt
index 800f083765..0c97a67267 100644
--- a/docs/topics/testing/tools.txt
+++ b/docs/topics/testing/tools.txt
@@ -237,10 +237,6 @@ Use the ``django.test.Client`` class to make requests.
         You may also provide any file-like object (e.g., :class:`~io.StringIO` or
         :class:`~io.BytesIO`) as a file handle.
 
-        .. versionadded:: 1.8
-
-            The ability to use a file-like object was added.
-
         Note that if you wish to use the same file handle for multiple
         ``post()`` calls then you will need to manually reset the file
         pointer between posts. The easiest way to do this is to
@@ -321,8 +317,6 @@ Use the ``django.test.Client`` class to make requests.
 
     .. method:: Client.trace(path, follow=False, secure=False, **extra)
 
-        .. versionadded:: 1.8
-
         Makes a TRACE request on the provided ``path`` and returns a
         ``Response`` object. Useful for simulating diagnostic probes.
 
@@ -496,8 +490,6 @@ Specifically, a ``Response`` object has the following attributes:
 
     .. attribute:: resolver_match
 
-       .. versionadded:: 1.8
-
         An instance of :class:`~django.core.urlresolvers.ResolverMatch` for the
         response. You can use the
         :attr:`~django.core.urlresolvers.ResolverMatch.func` attribute, for
@@ -698,14 +690,6 @@ transaction, as is required when using
 :meth:`~django.db.models.query.QuerySet.select_for_update()`. In those cases,
 you should use ``TransactionTestCase``.
 
-.. versionchanged:: 1.8
-
-    In older versions of Django, the effects of transaction commit and rollback
-    could not be tested within a ``TestCase``.  With the completion of the
-    deprecation cycle of the old-style transaction management in Django 1.8,
-    transaction management commands (e.g. ``transaction.commit()``) are no
-    longer disabled within ``TestCase``.
-
 ``TransactionTestCase`` and ``TestCase`` are identical except for the manner
 in which the database is reset to a known state and the ability for test code
 to test the effects of commit and rollback:
@@ -759,8 +743,6 @@ additions, including:
 
 .. classmethod:: TestCase.setUpTestData()
 
-    .. versionadded:: 1.8
-
     The class-level ``atomic`` block described above allows the creation of
     initial data at the class level, once for the whole ``TestCase``. This
     technique allows for faster tests as compared to using ``setUp()``.
@@ -1433,11 +1415,9 @@ your test suite.
 
     The name is a string such as ``'admin/index.html'``.
 
-    .. versionadded:: 1.8
-
-        The count argument is an integer indicating the number of times the
-        template should be rendered. Default is ``None``, meaning that the
-        template should be rendered one or more times.
+    The count argument is an integer indicating the number of times the
+    template should be rendered. Default is ``None``, meaning that the template
+    should be rendered one or more times.
 
     You can use this as a context manager, like this::
 
@@ -1562,8 +1542,6 @@ your test suite.
 
 .. method:: SimpleTestCase.assertJSONNotEqual(raw, expected_data, msg=None)
 
-    .. versionadded:: 1.8
-
     Asserts that the JSON fragments ``raw`` and ``expected_data`` are *not* equal.
     See :meth:`~SimpleTestCase.assertJSONEqual` for further details.
 
@@ -1724,10 +1702,6 @@ it would under MySQL with MyISAM tables)::
             # ... conditional test code
             pass
 
-.. versionchanged:: 1.8
-
-    ``skipIfDBFeature`` can accept multiple feature strings.
-
 .. function:: skipUnlessDBFeature(*feature_name_strings)
 
 Skip the decorated test or ``TestCase`` if any of the named database features
@@ -1742,7 +1716,3 @@ under MySQL with MyISAM tables)::
         def test_transaction_behavior(self):
             # ... conditional test code
             pass
-
-.. versionchanged:: 1.8
-
-    ``skipUnlessDBFeature`` can accept multiple feature strings.