Removed versionadded/changed annotations for 4.1.

12 files changed, 0 insertions, 82 deletions

diff --git a/docs/topics/async.txt b/docs/topics/async.txt
index 39ca864655..6308cfcbcb 100644
--- a/docs/topics/async.txt
+++ b/docs/topics/async.txt
@@ -76,8 +76,6 @@ corruption.
 Queries & the ORM
 -----------------
 
-.. versionadded:: 4.1
-
 With some exceptions, Django can run ORM queries asynchronously as well::
 
     async for author in Author.objects.filter(name__startswith="A"):
diff --git a/docs/topics/class-based-views/index.txt b/docs/topics/class-based-views/index.txt
index 1a6368cc08..206cf0a006 100644
--- a/docs/topics/class-based-views/index.txt
+++ b/docs/topics/class-based-views/index.txt
@@ -134,8 +134,6 @@ information, the client may or may not download the full object list.
 Asynchronous class-based views
 ==============================
 
-.. versionadded:: 4.1
-
 As well as the synchronous (``def``) method handlers already shown, ``View``
 subclasses may define asynchronous (``async def``) method handlers to leverage
 asynchronous code using ``await``::
diff --git a/docs/topics/db/queries.txt b/docs/topics/db/queries.txt
index 977e287c53..645d7eff38 100644
--- a/docs/topics/db/queries.txt
+++ b/docs/topics/db/queries.txt
@@ -857,8 +857,6 @@ being evaluated and therefore populate the cache::
 Asynchronous queries
 ====================
 
-.. versionadded:: 4.1
-
 If you are writing asynchronous views or code, you cannot use the ORM for
 queries in quite the way we have described above, as you cannot call *blocking*
 synchronous code from asynchronous code - it will block up the event loop
@@ -873,8 +871,6 @@ results, you can use asynchronous iteration (``async for``) instead.
 Query iteration
 ---------------
 
-.. versionadded:: 4.1
-
 The default way of iterating over a query - with ``for`` - will result in a
 blocking database query behind the scenes as Django loads the results at
 iteration time. To fix this, you can swap to ``async for``::
@@ -895,8 +891,6 @@ read the next section.
 ``QuerySet`` and manager methods
 --------------------------------
 
-.. versionadded:: 4.1
-
 Some methods on managers and querysets - like ``get()`` and ``first()`` - force
 execution of the queryset and are blocking. Some, like ``filter()`` and
 ``exclude()``, don't force execution and so are safe to run from asynchronous
@@ -938,8 +932,6 @@ the whole expression in order to call it in an asynchronous-friendly way.
 Transactions
 ------------
 
-.. versionadded:: 4.1
-
 Transactions are **not** currently supported with asynchronous queries and
 updates. You will find that trying to use one raises
 ``SynchronousOnlyOperation``.
@@ -1319,10 +1311,6 @@ precede the definition of any keyword arguments. For example::
     The :source:`OR lookups examples <tests/or_lookups/tests.py>` in Django's
     unit tests show some possible uses of ``Q``.
 
-.. versionchanged:: 4.1
-
-    Support for the ``^`` (``XOR``) operator was added.
-
 Comparing objects
 =================
 
diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt
index b41c9fa758..6c38a07555 100644
--- a/docs/topics/db/transactions.txt
+++ b/docs/topics/db/transactions.txt
@@ -238,11 +238,6 @@ Django provides a single API to control database transactions.
     is especially important if you're using :func:`atomic` in long-running
     processes, outside of Django's request / response cycle.
 
-.. versionchanged:: 4.1
-
-    In older versions, the durability check was disabled in
-    :class:`django.test.TestCase`.
-
 Autocommit
 ==========
 
diff --git a/docs/topics/forms/formsets.txt b/docs/topics/forms/formsets.txt
index 1624c380a1..3519951952 100644
--- a/docs/topics/forms/formsets.txt
+++ b/docs/topics/forms/formsets.txt
@@ -317,10 +317,6 @@ And here is a custom error message::
     >>> formset.non_form_errors()
     ['Sorry, something went wrong.']
 
-.. versionchanged:: 4.1
-
-    The ``'too_few_forms'`` and ``'too_many_forms'`` keys were added.
-
 Custom formset validation
 -------------------------
 
@@ -804,16 +800,8 @@ Formsets have the following attributes and methods associated with rendering:
     then each form in the formset as per the template defined by the form's
     :attr:`~django.forms.Form.template_name`.
 
-    .. versionchanged:: 4.1
-
-        In older versions ``template_name`` defaulted to the string value
-        ``'django/forms/formset/default.html'``.
-
-
 .. attribute:: BaseFormSet.template_name_div
 
-    .. versionadded:: 4.1
-
     The name of the template used when calling :meth:`.as_div`. By default this
     is ``"django/forms/formsets/div.html"``. This template renders the
     formset's management form and then each form in the formset as per the
diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt
index 464c6b86cb..a97acafc90 100644
--- a/docs/topics/forms/index.txt
+++ b/docs/topics/forms/index.txt
@@ -552,11 +552,6 @@ the :meth:`.Form.render`. Here's an example of this being used in a view::
 
 See :ref:`ref-forms-api-outputting-html` for more details.
 
-.. versionchanged:: 4.1
-
-    The ability to set the default ``form_template_name`` on the form renderer
-    was added.
-
 Form rendering options
 ----------------------
 
@@ -754,15 +749,11 @@ Useful attributes on ``{{ field }}`` include:
 
 ``{{ field.legend_tag }}``
 
-    .. versionadded:: 4.1
-
     Similar to ``field.label_tag`` but uses a ``<legend>`` tag in place of
     ``<label>``, for widgets with multiple inputs wrapped in a ``<fieldset>``.
 
 ``{{ field.use_fieldset }}``
 
-    .. versionadded:: 4.1
-
     This attribute is ``True`` if the form field's widget contains multiple
     inputs that should be semantically grouped in a ``<fieldset>`` with a
     ``<legend>`` to improve accessibility. An example use in a template:
diff --git a/docs/topics/forms/media.txt b/docs/topics/forms/media.txt
index 801d233244..b2327a8e02 100644
--- a/docs/topics/forms/media.txt
+++ b/docs/topics/forms/media.txt
@@ -118,11 +118,6 @@ If this last CSS definition were to be rendered, it would become the following H
     <link href="http://static.example.com/lo_res.css" media="tv,projector" rel="stylesheet">
     <link href="http://static.example.com/newspaper.css" media="print" rel="stylesheet">
 
-.. versionchanged:: 4.1
-
-    In older versions, the ``type="text/css"`` attribute is included in CSS
-    links.
-
 ``js``
 ------
 
@@ -260,8 +255,6 @@ Or if :mod:`~django.contrib.staticfiles` is configured using the
 Paths as objects
 ----------------
 
-.. versionadded:: 4.1
-
 Asset paths may also be given as hashable objects implementing an
 ``__html__()`` method. The ``__html__()`` method is typically added using the
 :func:`~django.utils.html.html_safe` decorator. The object is responsible for
diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt
index 349162abd1..253a4a01a4 100644
--- a/docs/topics/forms/modelforms.txt
+++ b/docs/topics/forms/modelforms.txt
@@ -995,8 +995,6 @@ of forms displayed (1000). In practice this is equivalent to no limit.
 Preventing new objects creation
 -------------------------------
 
-.. versionadded:: 4.1
-
 Using the ``edit_only`` parameter, you can prevent creation of any new
 objects::
 
diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt
index be3216c21f..c542773b4d 100644
--- a/docs/topics/migrations.txt
+++ b/docs/topics/migrations.txt
@@ -712,8 +712,6 @@ You must then transition the squashed migration to a normal migration by:
 
 .. admonition:: Pruning references to deleted migrations
 
-    .. versionadded:: 4.1
-
     If it is likely that you may reuse the name of a deleted migration in the
     future, you should remove references to it from Django’s migrations table
     with the :option:`migrate --prune` option.
diff --git a/docs/topics/signing.txt b/docs/topics/signing.txt
index 0e88c443cc..093a19f044 100644
--- a/docs/topics/signing.txt
+++ b/docs/topics/signing.txt
@@ -38,10 +38,6 @@ generate their own signed values.
 values will not be used to sign data, but if specified, they will be used to
 validate signed data and must be kept secure.
 
-.. versionchanged:: 4.1
-
-    The ``SECRET_KEY_FALLBACKS`` setting was added.
-
 Using the low-level API
 =======================
 
@@ -111,10 +107,6 @@ generate signatures. You can use a different secret by passing it to the
     of additional values used to validate signed data, defaults to
     :setting:`SECRET_KEY_FALLBACKS`.
 
-    .. versionchanged:: 4.1
-
-        The ``fallback_keys`` argument was added.
-
     .. deprecated:: 4.2
 
         Support for passing positional arguments is deprecated.
@@ -247,7 +239,3 @@ and tuples) if you pass in a tuple, you will get a list from
 
     Reverse of ``dumps()``, raises ``BadSignature`` if signature fails.
     Checks ``max_age`` (in seconds) if given.
-
-    .. versionchanged:: 4.1
-
-        The ``fallback_keys`` argument was added.
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