Removed versionadded/changed annotations for 1.8.

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

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:
 

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.