From 490cccbe7e83874923b276eed26cc23b0db5ebb9 Mon Sep 17 00:00:00 2001 From: Mariusz Felisiak Date: Fri, 6 Jan 2023 08:09:58 +0100 Subject: Removed versionadded/changed annotations for 4.1. --- docs/topics/testing/overview.txt | 4 ---- docs/topics/testing/tools.txt | 13 ------------- 2 files changed, 17 deletions(-) (limited to 'docs/topics/testing') 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 -- cgit v1.3