Removed versionadded/changed annotations for 4.1.

2 files changed, 0 insertions, 17 deletions

diff --git a/docs/topics/testing/overview.txt b/docs/topics/testing/overview.txt
index e37cf23737..394500b892 100644
--- a/docs/topics/testing/overview.txt
+++ b/docs/topics/testing/overview.txt
@@ -331,10 +331,6 @@ or an unexpected success). If all the tests pass, the return code is 0. This
 feature is useful if you're using the test-runner script in a shell script and
 need to test for success or failure at that level.
 
-.. versionchanged:: 4.1
-
-    In older versions, the return code was 0 for unexpected successes.
-
 .. _speeding-up-tests-auth-hashers:
 
 Speeding up the tests
diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt
index 1ecc97a2a9..7c8dd39cfb 100644
--- a/docs/topics/testing/tools.txt
+++ b/docs/topics/testing/tools.txt
@@ -1601,19 +1601,6 @@ your test suite.
     which means that ``errors='error message'`` is the same as
     ``errors=['error message']``.
 
-    .. versionchanged:: 4.1
-
-        In older versions, using an empty error list with ``assertFormError()``
-        would always pass, regardless of whether the field had any errors or
-        not. Starting from Django 4.1, using ``errors=[]`` will only pass if
-        the field actually has no errors.
-
-        Django 4.1 also changed the behavior of ``assertFormError()`` when a
-        field has multiple errors. In older versions, if a field had multiple
-        errors and you checked for only some of them, the test would pass.
-        Starting from Django 4.1, the error list must be an exact match to the
-        field's actual errors.
-
     .. deprecated:: 4.1
 
         Support for passing a response object and a form name to