Removed versionadded/changed annotations for 4.1.

docs/howto/custom-model-fields.txt

@@ -319,8 +319,6 @@ reconstructing the field::
 Field attributes not affecting database column definition
 ---------------------------------------------------------
 
-.. versionadded:: 4.1
-
 You can override ``Field.non_db_attrs`` to customize attributes of a field that
 don't affect a column definition. It's used during model migrations to detect
 no-op ``AlterField`` operations.

docs/howto/deployment/checklist.txt

@@ -70,11 +70,6 @@ If rotating secret keys, you may use :setting:`SECRET_KEY_FALLBACKS`::
 Ensure that old secret keys are removed from ``SECRET_KEY_FALLBACKS`` in a
 timely manner.
 
-.. versionchanged:: 4.1
-
-    The ``SECRET_KEY_FALLBACKS`` setting was added to support rotating secret
-    keys.
-
 :setting:`DEBUG`
 ----------------
 

docs/ref/class-based-views/base.txt

@@ -83,11 +83,6 @@ MRO is an acronym for Method Resolution Order.
         asynchronous (``async def``) and synchronous (``def``) handlers are
         defined on a single view-class.
 
-        .. versionchanged:: 4.1
-
-            Compatibility with asynchronous (``async def``) method handlers was
-            added.
-
     .. method:: setup(request, *args, **kwargs)
 
         Performs key view initialization prior to :meth:`dispatch`.
@@ -126,11 +121,6 @@ MRO is an acronym for Method Resolution Order.
         (``async def``) then the response will be wrapped in a coroutine
         function for use with ``await``.
 
-        .. versionchanged:: 4.1
-
-            Compatibility with classes defining asynchronous (``async def``)
-            method handlers was added.
-
 ``TemplateView``
 ================
 

docs/ref/contrib/admin/index.txt

@@ -1186,22 +1186,6 @@ subclass::
     :meth:`ModelAdmin.get_search_results` to provide additional or alternate
     search behavior.
 
-    .. versionchanged:: 4.1
-
-        Searches using multiple search terms are now applied in a single call
-        to ``filter()``, rather than in sequential ``filter()`` calls.
-
-        For multi-valued relationships, this means that rows from the related
-        model must match all terms rather than any term. For example, if
-        ``search_fields`` is set to ``['child__name', 'child__age']``, and a
-        user searches for ``'Jamal 17'``, parent rows will be returned only if
-        there is a relationship to some 17-year-old child named Jamal, rather
-        than also returning parents who merely have a younger or older child
-        named Jamal in addition to some other 17-year-old.
-
-        See the :ref:`spanning-multi-valued-relationships` topic for more
-        discussion of this difference.
-
 .. attribute:: ModelAdmin.search_help_text
 
     Set ``search_help_text`` to specify a descriptive text for the search box
@@ -1418,22 +1402,6 @@ templates used by the :class:`ModelAdmin` views:
     field, for example ``... OR UPPER("polls_choice"."votes"::text) = UPPER('4')``
     on PostgreSQL.
 
-    .. versionchanged:: 4.1
-
-        Searches using multiple search terms are now applied in a single call
-        to ``filter()``, rather than in sequential ``filter()`` calls.
-
-        For multi-valued relationships, this means that rows from the related
-        model must match all terms rather than any term. For example, if
-        ``search_fields`` is set to ``['child__name', 'child__age']``, and a
-        user searches for ``'Jamal 17'``, parent rows will be returned only if
-        there is a relationship to some 17-year-old child named Jamal, rather
-        than also returning parents who merely have a younger or older child
-        named Jamal in addition to some other 17-year-old.
-
-        See the :ref:`spanning-multi-valued-relationships` topic for more
-        discussion of this difference.
-
 .. _Solr: https://solr.apache.org
 .. _Haystack: https://haystacksearch.org
 
@@ -1999,10 +1967,6 @@ Other methods
     Django view for the page that shows the modification history for a given
     model instance.
 
-    .. versionchanged:: 4.1
-
-        Pagination was added.
-
 Unlike the hook-type ``ModelAdmin`` methods detailed in the previous section,
 these five methods are in reality designed to be invoked as Django views from
 the admin application URL dispatching handler to render the pages that deal
@@ -2725,11 +2689,6 @@ linked to the document in ``{% block dark-mode-vars %}``.
 
 .. _prefers-color-scheme: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme
 
-.. versionchanged:: 4.1
-
-    The dark mode variables were moved to a separate stylesheet and template
-    block.
-
 ``AdminSite`` objects
 =====================
 
@@ -2900,10 +2859,6 @@ Templates can override or extend base admin templates as described in
     You can override this method to change the default order on the admin index
     page.
 
-    .. versionchanged:: 4.1
-
-        The ``app_label`` argument was added.
-
 .. method:: AdminSite.has_permission(request)
 
     Returns ``True`` if the user for the given ``HttpRequest`` has permission

docs/ref/contrib/admin/javascript.txt

@@ -12,12 +12,6 @@ in the admin change form. The ``formset:added`` and ``formset:removed`` events
 allow this. ``event.detail.formsetName`` is the formset the row belongs to.
 For the ``formset:added`` event, ``event.target`` is the newly added row.
 
-.. versionchanged:: 4.1
-
-    In older versions, the event was a ``jQuery`` event with ``$row`` and
-    ``formsetName`` parameters. It is now a JavaScript ``CustomEvent`` with
-    parameters set in ``event.detail``.
-
 In your custom ``change_form.html`` template, extend the
 ``admin_change_form_document_ready`` block and add the event listener code:
 

docs/ref/contrib/auth.txt

@@ -666,10 +666,6 @@ The following backends are available in :mod:`django.contrib.auth.backends`:
         if it wasn't provided to :func:`~django.contrib.auth.authenticate`
         (which passes it on to the backend).
 
-        .. versionchanged:: 4.1
-
-            The ``created`` argument was added.
-
     .. method:: user_can_authenticate()
 
         Returns whether the user is allowed to authenticate. This method

docs/ref/contrib/gis/geos.txt

@@ -659,8 +659,6 @@ Other Properties & Methods
 
 .. method:: GEOSGeometry.make_valid()
 
-    .. versionadded:: 4.1
-
     Returns a valid :class:`GEOSGeometry` equivalent, trying not to lose any of
     the input vertices. If the geometry is already valid, it is returned
     untouched. This is similar to the
@@ -680,10 +678,6 @@ Other Properties & Methods
         >>> print(g)
         MULTIPOINT (2 2, 1 1, 0 0)
 
-    .. versionchanged:: 4.1
-
-        The ``clone`` argument was added.
-
 ``Point``
 ---------
 

docs/ref/contrib/postgres/aggregates.txt

@@ -78,8 +78,6 @@ General-purpose aggregation functions
 ``BitXor``
 ----------
 
-.. versionadded:: 4.1
-
 .. class:: BitXor(expression, filter=None, default=None, **extra)
 
     Returns an ``int`` of the bitwise ``XOR`` of all non-null input values, or

docs/ref/contrib/postgres/constraints.txt

@@ -30,11 +30,6 @@ PostgreSQL supports additional data integrity constraints available from the
     Exclusion constraints are checked during the :ref:`model validation
     <validating-objects>`.
 
-    .. versionchanged:: 4.1
-
-        In older versions, exclusion constraints were not checked during model
-        validation.
-
 ``name``
 --------
 
@@ -71,10 +66,6 @@ For example::
 
 creates an exclusion constraint on ``circle`` using ``circle_ops``.
 
-.. versionchanged:: 4.1
-
-    Support for the ``OpClass()`` expression was added.
-
 .. _operator class: https://www.postgresql.org/docs/current/indexes-opclass.html
 
 ``index_type``
@@ -142,11 +133,6 @@ used for queries that select only included fields
 ``include`` is supported for GiST indexes. PostgreSQL 14+ also supports
 ``include`` for SP-GiST indexes.
 
-.. versionchanged:: 4.1
-
-    Support for covering exclusion constraints using SP-GiST indexes on
-    PostgreSQL 14+ was added.
-
 ``opclasses``
 -------------
 
@@ -176,8 +162,6 @@ creates an exclusion constraint on ``circle`` using ``circle_ops``.
 ``violation_error_message``
 ---------------------------
 
-.. versionadded:: 4.1
-
 The error message used when ``ValidationError`` is raised during
 :ref:`model validation <validating-objects>`. Defaults to
 :attr:`.BaseConstraint.violation_error_message`.

docs/ref/contrib/postgres/fields.txt

@@ -586,8 +586,6 @@ the ``default_bounds`` argument.
 
     .. attribute:: DecimalRangeField.default_bounds
 
-        .. versionadded:: 4.1
-
         Optional. The value of ``bounds`` for list and tuple inputs. The
         default is lower bound included, upper bound excluded, that is ``[)``
         (see the PostgreSQL documentation for details about
@@ -606,8 +604,6 @@ the ``default_bounds`` argument.
 
     .. attribute:: DateTimeRangeField.default_bounds
 
-        .. versionadded:: 4.1
-
         Optional. The value of ``bounds`` for list and tuple inputs. The
         default is lower bound included, upper bound excluded, that is ``[)``
         (see the PostgreSQL documentation for details about

docs/ref/contrib/postgres/indexes.txt

@@ -133,10 +133,6 @@ available from the ``django.contrib.postgres.indexes`` module.
     Provide an integer value from 10 to 100 to the fillfactor_ parameter to
     tune how packed the index pages will be. PostgreSQL's default is 90.
 
-    .. versionchanged:: 4.1
-
-        Support for covering SP-GiST indexes on PostgreSQL 14+ was added.
-
     .. _fillfactor: https://www.postgresql.org/docs/current/sql-createindex.html#SQL-CREATEINDEX-STORAGE-PARAMETERS
 
 ``OpClass()`` expressions
@@ -178,8 +174,4 @@ available from the ``django.contrib.postgres.indexes`` module.
 
     creates an exclusion constraint on ``circle`` using ``circle_ops``.
 
-    .. versionchanged:: 4.1
-
-        Support for exclusion constraints was added.
-
     .. _operator class: https://www.postgresql.org/docs/current/indexes-opclass.html

docs/ref/contrib/sitemaps.txt

@@ -296,8 +296,6 @@ Note:
 
     .. method:: Sitemap.get_latest_lastmod()
 
-        .. versionadded:: 4.1
-
         **Optional.** A method that returns the latest value returned by
         :attr:`~Sitemap.lastmod`. This function is used to add the ``lastmod``
         attribute to :ref:`Sitemap index context
@@ -465,10 +463,6 @@ with a caching decorator -- you must name your sitemap view and pass
              {'sitemaps': sitemaps}, name='sitemaps'),
     ]
 
-.. versionchanged:: 4.1
-
-    Use of the ``Last-Modified`` header was added.
-
 Template customization
 ======================
 
@@ -516,11 +510,6 @@ attributes:
 - ``lastmod``: Populated by the :meth:`~Sitemap.get_latest_lastmod`
   method for each sitemap.
 
-.. versionchanged:: 4.1
-
-    The context was changed to a list of objects with ``location`` and optional
-    ``lastmod`` attributes.
-
 Sitemap
 -------
 

docs/ref/contrib/staticfiles.txt

@@ -330,10 +330,6 @@ argument. For example::
             manifest_storage = StaticFilesStorage(location=settings.BASE_DIR)
             super().__init__(*args, manifest_storage=manifest_storage, **kwargs)
 
-.. versionchanged:: 4.1
-
-    Support for finding paths in CSS source map comments was added.
-
 .. versionchanged:: 4.2
 
     Support for finding paths to JavaScript modules in ``import`` and

docs/ref/csrf.txt

@@ -82,10 +82,6 @@ The CSRF protection is based on the following things:
    Expanding the accepted referers beyond the current host or cookie domain can
    be done with the :setting:`CSRF_TRUSTED_ORIGINS` setting.
 
-.. versionchanged:: 4.1
-
-    In older versions, the CSRF cookie value was masked.
-
 This ensures that only forms that have originated from trusted domains can be
 used to POST data back.
 

docs/ref/databases.txt

@@ -72,10 +72,6 @@ connections, e.g. after database server restart. The health check is performed
 only once per request and only if the database is being accessed during the
 handling of the request.
 
-.. versionchanged:: 4.1
-
-    The :setting:`CONN_HEALTH_CHECKS` setting was added.
-
 Caveats
 ~~~~~~~
 
@@ -367,11 +363,6 @@ If you need to specify such values, reset the sequence afterward to avoid
 reusing a value that's already in the table. The :djadmin:`sqlsequencereset`
 management command generates the SQL statements to do that.
 
-.. versionchanged:: 4.1
-
-    In older versions, PostgreSQL’s ``SERIAL`` data type was used instead of
-    identity columns.
-
 .. _sequence: https://www.postgresql.org/docs/current/sql-createsequence.html
 
 Test database templates

docs/ref/django-admin.txt

@@ -715,8 +715,6 @@ migrations are detected.
 
 .. django-admin-option:: --scriptable
 
-.. versionadded:: 4.1
-
 Diverts log output and input prompts to ``stderr``, writing only paths of
 generated migration files to ``stdout``.
 
@@ -805,8 +803,6 @@ detected.
 
 .. django-admin-option:: --prune
 
-.. versionadded:: 4.1
-
 Deletes nonexistent migrations from the ``django_migrations`` table. This is
 useful when migration files replaced by a squashed migration have been removed.
 See :ref:`migration-squashing` for more details.
@@ -814,8 +810,6 @@ See :ref:`migration-squashing` for more details.
 ``optimizemigration``
 ---------------------
 
-.. versionadded:: 4.1
-
 .. django-admin:: optimizemigration app_label migration_name
 
 Optimizes the operations for the named migration and overrides the existing
@@ -1961,8 +1955,6 @@ See :doc:`/howto/custom-management-commands` for how to add customized actions.
 Black formatting
 ----------------
 
-.. versionadded:: 4.1
-
 The Python files created by :djadmin:`startproject`, :djadmin:`startapp`,
 :djadmin:`optimizemigration`, :djadmin:`makemigrations`, and
 :djadmin:`squashmigrations` are formatted using the ``black`` command if it is

docs/ref/forms/api.txt

@@ -539,11 +539,6 @@ By default, a property returning the value of the renderer's
 as a string template name in order to override that for a particular form
 class.
 
-.. versionchanged:: 4.1
-
-    In older versions ``template_name`` defaulted to the string value
-    ``'django/forms/default.html'``.
-
 ``render()``
 ~~~~~~~~~~~~
 
@@ -604,14 +599,10 @@ template name.
 
 .. attribute:: Form.template_name_div
 
-.. versionadded:: 4.1
-
 The template used by ``as_div()``. Default: ``'django/forms/div.html'``.
 
 .. method:: Form.as_div()
 
-.. versionadded:: 4.1
-
 ``as_div()`` renders the form as a series of ``<div>`` elements, with each
 ``<div>`` containing one field, such as:
 
@@ -1196,8 +1187,6 @@ Attributes of ``BoundField``
 
 .. attribute:: BoundField.use_fieldset
 
-    .. versionadded:: 4.1
-
     Returns the value of this BoundField widget's ``use_fieldset`` attribute.
 
 .. attribute:: BoundField.widget_type
@@ -1292,14 +1281,8 @@ Methods of ``BoundField``
     overriding the default template, see also
     :ref:`overriding-built-in-form-templates`.
 
-    .. versionchanged:: 4.1
-
-        The ``tag`` argument was added.
-
 .. method:: BoundField.legend_tag(contents=None, attrs=None, label_suffix=None)
 
-    .. versionadded:: 4.1
-
     Calls :meth:`.label_tag` with ``tag='legend'`` to render the label with
     ``<legend>`` tags. This is useful when rendering radio and multiple
     checkbox widgets where ``<legend>`` may be more appropriate than a

docs/ref/forms/fields.txt

@@ -527,10 +527,6 @@ For each field, we describe the default widget used if you don't specify
 
         Limit valid inputs to an integral multiple of ``step_size``.
 
-    .. versionchanged:: 4.1
-
-        The ``step_size`` argument was added.
-
 ``DurationField``
 -----------------
 
@@ -662,8 +658,6 @@ For each field, we describe the default widget used if you don't specify
 
     .. attribute:: step_size
 
-        .. versionadded:: 4.1
-
         Limit valid inputs to an integral multiple of ``step_size``.
 
 ``GenericIPAddressField``
@@ -797,8 +791,6 @@ For each field, we describe the default widget used if you don't specify
 
     .. attribute:: step_size
 
-        .. versionadded:: 4.1
-
         Limit valid inputs to an integral multiple of ``step_size``.
 
 ``JSONField``

docs/ref/forms/models.txt

@@ -72,10 +72,6 @@ Model Form API reference. For introductory material about model forms, see the
 
     See :ref:`model-formsets` for example usage.
 
-    .. versionchanged:: 4.1
-
-        The ``edit_only`` argument was added.
-
 ``inlineformset_factory``
 =========================
 
@@ -89,7 +85,3 @@ Model Form API reference. For introductory material about model forms, see the
     the ``parent_model``, you must specify a ``fk_name``.
 
     See :ref:`inline-formsets` for example usage.
-
-    .. versionchanged:: 4.1
-
-        The ``edit_only`` argument was added.

docs/ref/forms/renderers.txt

@@ -49,8 +49,6 @@ should return a rendered templates (as a string) or raise
 
     .. attribute:: form_template_name
 
-        .. versionadded:: 4.1
-
         The default name of the template to use to render a form.
 
         Defaults to ``"django/forms/default.html"``, which is a proxy for
@@ -64,8 +62,6 @@ should return a rendered templates (as a string) or raise
 
     .. attribute:: formset_template_name
 
-        .. versionadded:: 4.1
-
         The default name of the template to use to render a formset.
 
         Defaults to ``"django/forms/formsets/default.html"``, which is a proxy
@@ -111,8 +107,6 @@ If you want to render templates with customizations from your
 
 .. class:: DjangoDivFormRenderer
 
-.. versionadded:: 4.1
-
 Subclass of :class:`DjangoTemplates` that specifies
 :attr:`~BaseRenderer.form_template_name` and
 :attr:`~BaseRenderer.formset_template_name` as ``"django/forms/div.html"`` and
@@ -147,8 +141,6 @@ widgets due to their usage of Django template tags.
 
 .. class:: Jinja2DivFormRenderer
 
-.. versionadded:: 4.1
-
 A transitional renderer as per :class:`DjangoDivFormRenderer` above, but
 subclassing :class:`Jinja2` for use with the Jinja2 backend.
 

docs/ref/forms/widgets.txt

@@ -318,8 +318,6 @@ foundation for custom widgets.
 
     .. attribute:: Widget.use_fieldset
 
-        .. versionadded:: 4.1
-
         An attribute to identify if the widget should be grouped in a
         ``<fieldset>`` with a ``<legend>`` when rendered. Defaults to ``False``
         but is ``True`` when the widget contains multiple ``<input>`` tags such as

docs/ref/migration-operations.txt

@@ -244,8 +244,6 @@ Removes the index named ``name`` from the model with ``model_name``.
 ``RenameIndex``
 ---------------
 
-.. versionadded:: 4.1
-
 .. class:: RenameIndex(model_name, new_name, old_name=None, old_fields=None)
 
 Renames an index in the database table for the model with ``model_name``.

docs/ref/models/constraints.txt

@@ -45,10 +45,6 @@ option.
     ``django.db.models`` logger, like *"Got a database error calling check() on
     …"* to confirm it's validated properly.
 
-.. versionchanged:: 4.1
-
-    In older versions, constraints were not checked during model validation.
-
 ``BaseConstraint``
 ==================
 
@@ -71,8 +67,6 @@ constraint.
 ``violation_error_message``
 ---------------------------
 
-.. versionadded:: 4.1
-
 .. attribute:: BaseConstraint.violation_error_message
 
 The error message used when ``ValidationError`` is raised during
@@ -82,8 +76,6 @@ The error message used when ``ValidationError`` is raised during
 ``validate()``
 --------------
 
-.. versionadded:: 4.1
-
 .. method:: BaseConstraint.validate(model, instance, exclude=None, using=DEFAULT_DB_ALIAS)
 
 Validates that the constraint, defined on ``model``, is respected on the
@@ -122,10 +114,6 @@ ensures the age field is never less than 18.
 
         CheckConstraint(check=Q(age__gte=18) | Q(age__isnull=True), name='age_gte_18')
 
-.. versionchanged:: 4.1
-
-    The ``violation_error_message`` argument was added.
-
 ``UniqueConstraint``
 ====================
 
@@ -253,8 +241,6 @@ creates a unique index on ``username`` using ``varchar_pattern_ops``.
 ``violation_error_message``
 ---------------------------
 
-.. versionadded:: 4.1
-
 .. attribute:: UniqueConstraint.violation_error_message
 
 The error message used when ``ValidationError`` is raised during

docs/ref/models/expressions.txt

@@ -784,10 +784,6 @@ and second row.
 The ``frame`` parameter specifies which other rows that should be used in the
 computation. See :ref:`window-frames` for details.
 
-.. versionchanged:: 4.1
-
-    Support for ``order_by`` by field name references was added.
-
 For example, to annotate each movie with the average rating for the movies by
 the same studio in the same genre and release year::
 
@@ -1067,11 +1063,6 @@ calling the appropriate methods on the wrapped expression.
         ``nulls_first`` and ``nulls_last`` define how null values are sorted.
         See :ref:`using-f-to-sort-null-values` for example usage.
 
-        .. versionchanged:: 4.1
-
-            In older versions, ``nulls_first`` and ``nulls_last`` defaulted to
-            ``False``.
-
         .. deprecated:: 4.1
 
             Passing ``nulls_first=False`` or ``nulls_last=False`` to ``asc()``
@@ -1084,11 +1075,6 @@ calling the appropriate methods on the wrapped expression.
         ``nulls_first`` and ``nulls_last`` define how null values are sorted.
         See :ref:`using-f-to-sort-null-values` for example usage.
 
-        .. versionchanged:: 4.1
-
-            In older versions, ``nulls_first`` and ``nulls_last`` defaulted to
-            ``False``.
-
         .. deprecated:: 4.1
 
             Passing ``nulls_first=False`` or ``nulls_last=False`` to ``desc()``

docs/ref/models/indexes.txt

@@ -219,8 +219,4 @@ See the PostgreSQL documentation for more details about `covering indexes`_.
     covering :class:`SP-GiST indexes
     <django.contrib.postgres.indexes.SpGistIndex>`.
 
-.. versionchanged:: 4.1
-
-    Support for covering SP-GiST indexes with PostgreSQL 14+ was added.
-
 .. _covering indexes: https://www.postgresql.org/docs/current/indexes-index-only-scans.html

docs/ref/models/instances.txt

@@ -229,11 +229,6 @@ validation errors yourself, or if you have excluded fields from the
     ``django.db.models`` logger, like *"Got a database error calling check() on
     …"* to confirm it's validated properly.
 
-.. versionchanged:: 4.1
-
-    In older versions, constraints were not checked during the model
-    validation.
-
 .. method:: Model.full_clean(exclude=None, validate_unique=True, validate_constraints=True)
 
 This method calls :meth:`Model.clean_fields()`, :meth:`Model.clean()`,
@@ -263,14 +258,6 @@ models. For example::
 
 The first step ``full_clean()`` performs is to clean each individual field.
 
-.. versionchanged:: 4.1
-
-    The ``validate_constraints`` argument was added.
-
-.. versionchanged:: 4.1
-
-    An ``exclude`` value is now converted to a ``set`` rather than a ``list``.
-
 .. method:: Model.clean_fields(exclude=None)
 
 This method will validate all fields on your model. The optional ``exclude``
@@ -391,15 +378,8 @@ the fields you provided will not be checked.
 
 Finally, ``full_clean()`` will check any other constraints on your model.
 
-.. versionchanged:: 4.1
-
-    In older versions, :class:`~django.db.models.UniqueConstraint`\s were
-    validated by ``validate_unique()``.
-
 .. method:: Model.validate_constraints(exclude=None)
 
-.. versionadded:: 4.1
-
 This method validates all constraints defined in
 :attr:`Meta.constraints <django.db.models.Options.constraints>`. The
 optional ``exclude`` argument allows you to provide a ``set`` of field names to

docs/ref/models/querysets.txt

@@ -43,10 +43,6 @@ You can evaluate a ``QuerySet`` in the following ways:
   Both synchronous and asynchronous iterators of QuerySets share the same
   underlying cache.
 
-  .. versionchanged:: 4.1
-
-    Support for asynchronous iteration was added.
-
 * **Slicing.** As explained in :ref:`limiting-querysets`, a ``QuerySet`` can
   be sliced, using Python's array-slicing syntax. Slicing an unevaluated
   ``QuerySet`` usually returns another unevaluated ``QuerySet``, but Django
@@ -1250,10 +1246,8 @@ could be generated, which, depending on the database, might have performance
 problems of its own when it comes to parsing or executing the SQL query. Always
 profile for your use case!
 
-.. versionchanged:: 4.1
-
-    If you use ``iterator()`` to run the query, ``prefetch_related()``
-    calls will only be observed if a value for ``chunk_size`` is provided.
+If you use ``iterator()`` to run the query, ``prefetch_related()`` calls will
+only be observed if a value for ``chunk_size`` is provided.
 
 You can use the :class:`~django.db.models.Prefetch` object to further control
 the prefetch operation.
@@ -1955,8 +1949,6 @@ may be generated.
 XOR (``^``)
 ~~~~~~~~~~~
 
-.. versionadded:: 4.1
-
 Combines two ``QuerySet``\s using the SQL ``XOR`` operator.
 
 The following are equivalent::
@@ -2003,10 +1995,6 @@ this reason, each has a corresponding asynchronous version with an ``a`` prefix
 There is usually no difference in behavior apart from their asynchronous
 nature, but any differences are noted below next to each method.
 
-.. versionchanged:: 4.1
-
-    The asynchronous versions of each method, prefixed with ``a`` was added.
-
 ``get()``
 ~~~~~~~~~
 
@@ -2053,10 +2041,6 @@ can use :exc:`django.core.exceptions.ObjectDoesNotExist`  to handle
     except ObjectDoesNotExist:
         print("Either the blog or entry doesn't exist.")
 
-.. versionchanged:: 4.1
-
-    ``aget()`` method was added.
-
 ``create()``
 ~~~~~~~~~~~~
 
@@ -2084,10 +2068,6 @@ database, a call to ``create()`` will fail with an
 :exc:`~django.db.IntegrityError` since primary keys must be unique. Be
 prepared to handle the exception if you are using manual primary keys.
 
-.. versionchanged:: 4.1
-
-    ``acreate()`` method was added.
-
 ``get_or_create()``
 ~~~~~~~~~~~~~~~~~~~
 
@@ -2216,10 +2196,6 @@ whenever a request to a page has a side effect on your data. For more, see
   chapter because it isn't related to that book, but it can't create it either
   because ``title`` field should be unique.
 
-.. versionchanged:: 4.1
-
-    ``aget_or_create()`` method was added.
-
 ``update_or_create()``
 ~~~~~~~~~~~~~~~~~~~~~~
 
@@ -2273,10 +2249,6 @@ Like :meth:`get_or_create` and :meth:`create`, if you're using manually
 specified primary keys and an object needs to be created but the key already
 exists in the database, an :exc:`~django.db.IntegrityError` is raised.
 
-.. versionchanged:: 4.1
-
-    ``aupdate_or_create()`` method was added.
-
 .. versionchanged:: 4.2
 
     In older versions, ``update_or_create()`` didn't specify ``update_fields``
@@ -2354,14 +2326,6 @@ support it).
 .. _MySQL documentation: https://dev.mysql.com/doc/refman/en/sql-mode.html#ignore-strict-comparison
 .. _MariaDB documentation: https://mariadb.com/kb/en/ignore/
 
-.. versionchanged:: 4.1
-
-    The ``update_conflicts``, ``update_fields``, and ``unique_fields``
-    parameters were added to support updating fields when a row insertion fails
-    on conflict.
-
-    ``abulk_create()`` method was added.
-
 ``bulk_update()``
 ~~~~~~~~~~~~~~~~~
 
@@ -2407,10 +2371,6 @@ The ``batch_size`` parameter controls how many objects are saved in a single
 query. The default is to update all objects in one batch, except for SQLite
 and Oracle which have restrictions on the number of variables used in a query.
 
-.. versionchanged:: 4.1
-
-    ``abulk_update()`` method was added.
-
 ``count()``
 ~~~~~~~~~~~
 
@@ -2443,10 +2403,6 @@ database query like ``count()`` would.
 If the queryset has already been fully retrieved, ``count()`` will use that
 length rather than perform an extra database query.
 
-.. versionchanged:: 4.1
-
-    ``acount()`` method was added.
-
 ``in_bulk()``
 ~~~~~~~~~~~~~
 
@@ -2482,10 +2438,6 @@ Example::
 
 If you pass ``in_bulk()`` an empty list, you'll get an empty dictionary.
 
-.. versionchanged:: 4.1
-
-    ``ain_bulk()`` method was added.
-
 ``iterator()``
 ~~~~~~~~~~~~~~
 
@@ -2532,12 +2484,6 @@ value for ``chunk_size`` will result in Django using an implicit default of
 Depending on the database backend, query results will either be loaded all at
 once or streamed from the database using server-side cursors.
 
-.. versionchanged:: 4.1
-
-    Support for prefetching related objects was added to ``iterator()``.
-
-    ``aiterator()`` method was added.
-
 .. deprecated:: 4.1
 
     Using ``iterator()`` on a queryset that prefetches related objects without
@@ -2640,10 +2586,6 @@ readability.
 
         Entry.objects.filter(pub_date__isnull=False).latest('pub_date')
 
-.. versionchanged:: 4.1
-
-    ``alatest()`` method was added.
-
 ``earliest()``
 ~~~~~~~~~~~~~~
 
@@ -2655,10 +2597,6 @@ readability.
 Works otherwise like :meth:`~django.db.models.query.QuerySet.latest` except
 the direction is changed.
 
-.. versionchanged:: 4.1
-
-    ``aearliest()`` method was added.
-
 ``first()``
 ~~~~~~~~~~~
 
@@ -2684,10 +2622,6 @@ equivalent to the above example::
     except IndexError:
         p = None
 
-.. versionchanged:: 4.1
-
-    ``afirst()`` method was added.
-
 ``last()``
 ~~~~~~~~~~
 
@@ -2698,10 +2632,6 @@ equivalent to the above example::
 
 Works like  :meth:`first()`, but returns the last object in the queryset.
 
-.. versionchanged:: 4.1
-
-    ``alast()`` method was added.
-
 ``aggregate()``
 ~~~~~~~~~~~~~~~
 
@@ -2741,10 +2671,6 @@ control the name of the aggregation value that is returned::
 For an in-depth discussion of aggregation, see :doc:`the topic guide on
 Aggregation </topics/db/aggregation>`.
 
-.. versionchanged:: 4.1
-
-    ``aaggregate()`` method was added.
-
 ``exists()``
 ~~~~~~~~~~~~
 
@@ -2781,10 +2707,6 @@ more overall work (one query for the existence check plus an extra one to later
 retrieve the results) than using ``bool(some_queryset)``, which retrieves the
 results and then checks if any were returned.
 
-.. versionchanged:: 4.1
-
-    ``aexists()`` method was added.
-
 ``contains()``
 ~~~~~~~~~~~~~~
 
@@ -2815,10 +2737,6 @@ know that it will be at some point, then using ``some_queryset.contains(obj)``
 will make an additional database query, generally resulting in slower overall
 performance.
 
-.. versionchanged:: 4.1
-
-    ``acontains()`` method was added.
-
 ``update()``
 ~~~~~~~~~~~~
 
@@ -2896,10 +2814,6 @@ update a bunch of records for a model that has a custom
         e.comments_on = False
         e.save()
 
-.. versionchanged:: 4.1
-
-    ``aupdate()`` method was added.
-
 Ordered queryset
 ^^^^^^^^^^^^^^^^
 
@@ -2971,10 +2885,6 @@ ForeignKeys which are set to :attr:`~django.db.models.ForeignKey.on_delete`
 Note that the queries generated in object deletion is an implementation
 detail subject to change.
 
-.. versionchanged:: 4.1
-
-    ``adelete()`` method was added.
-
 ``as_manager()``
 ~~~~~~~~~~~~~~~~
 
@@ -3033,10 +2943,6 @@ adverse effects on your database. For example, the ``ANALYZE`` flag supported
 by MariaDB, MySQL 8.0.18+, and PostgreSQL could result in changes to data if
 there are triggers or if a function is called, even for a ``SELECT`` query.
 
-.. versionchanged:: 4.1
-
-    ``aexplain()`` method was added.
-
 .. _field-lookups:
 
 ``Field`` lookups
@@ -3982,10 +3888,6 @@ or annotation. They make it possible to define and reuse conditions, and
 combine them using operators such as ``|`` (``OR``), ``&`` (``AND``), and ``^``
 (``XOR``). See :ref:`complex-lookups-with-q`.
 
-.. versionchanged:: 4.1
-
-    Support for the ``^`` (``XOR``) operator was added.
-
 ``Prefetch()`` objects
 ----------------------
 

docs/ref/models/relations.txt

@@ -120,10 +120,6 @@ Related objects reference
         needed. You can use callables as values in the ``through_defaults``
         dictionary.
 
-        .. versionchanged:: 4.1
-
-            ``acreate()`` method was added.
-
     .. method:: remove(*objs, bulk=True)
     .. method:: aremove(*objs, bulk=True)
 

docs/ref/request-response.txt

@@ -857,11 +857,6 @@ Methods
       number of seconds, or ``None`` (default) if the cookie should last only
       as long as the client's browser session. If ``expires`` is not specified,
       it will be calculated.
-
-      .. versionchanged:: 4.1
-
-        Support for ``timedelta`` objects was added.
-
     * ``expires`` should either be a string in the format
       ``"Wdy, DD-Mon-YY HH:MM:SS GMT"`` or a ``datetime.datetime`` object
       in UTC. If ``expires`` is a ``datetime`` object, the ``max_age``

docs/ref/schema-editor.txt

@@ -82,8 +82,6 @@ Removes ``index`` from ``model``’s table.
 ``rename_index()``
 ------------------
 
-.. versionadded:: 4.1
-
 .. method:: BaseDatabaseSchemaEditor.rename_index(model, old_index, new_index)
 
 Renames ``old_index`` from ``model``’s table to ``new_index``.

docs/ref/settings.txt

@@ -348,8 +348,6 @@ See :setting:`SESSION_COOKIE_HTTPONLY` for details on ``HttpOnly``.
 ``CSRF_COOKIE_MASKED``
 ----------------------
 
-.. versionadded:: 4.1
-
 Default: ``False``
 
 Whether to mask the CSRF cookie. See
@@ -625,8 +623,6 @@ behavior — and ``None`` for unlimited :ref:`persistent database connections
 ``CONN_HEALTH_CHECKS``
 ~~~~~~~~~~~~~~~~~~~~~~
 
-.. versionadded:: 4.1
-
 Default: ``False``
 
 If set to ``True``, existing :ref:`persistent database connections
@@ -2311,8 +2307,6 @@ passwords of users and key rotation will not affect them.
 ``SECRET_KEY_FALLBACKS``
 ------------------------
 
-.. versionadded:: 4.1
-
 Default: ``[]``
 
 A list of fallback secret keys for a particular Django installation. These are
@@ -2444,11 +2438,6 @@ in via HTTPS) when:
 * its initial, leftmost value is ``'https'`` in the case of a comma-separated
   list of protocols (e.g. ``'https,http,http'``).
 
-.. versionchanged:: 4.1
-
-    Support for a comma-separated list of protocols in the header value was
-    added.
-
 You should *only* set this setting if you control your proxy or have some other
 guarantee that it sets/strips this header appropriately.
 

docs/ref/signals.txt

@@ -204,7 +204,6 @@ Arguments sent with this signal:
     The database alias being used.
 
 ``origin``
-    .. versionadded:: 4.1
 
     The origin of the deletion being the instance of a ``Model`` or
     ``QuerySet`` class.
@@ -234,7 +233,6 @@ Arguments sent with this signal:
     The database alias being used.
 
 ``origin``
-    .. versionadded:: 4.1
 
     The origin of the deletion being the instance of a ``Model`` or
     ``QuerySet`` class.

docs/ref/templates/api.txt

@@ -102,11 +102,6 @@ overridden by what's passed by
       These loaders are then wrapped in
       :class:`django.template.loaders.cached.Loader`.
 
-      .. versionchanged:: 4.1
-
-        In older versions, the cached template loader was only enabled by
-        default when ``DEBUG`` was ``False``.
-
       See :ref:`template-loaders` for details.
 
     * ``string_if_invalid`` is the output, as a string, that the template
@@ -949,12 +944,6 @@ loaders that come with Django:
         information, see :ref:`template tag thread safety considerations
         <template_tag_thread_safety>`.
 
-    .. versionchanged:: 4.1
-
-        The cached template loader was enabled whenever ``OPTIONS['loaders']``
-        is not specified. Previously it was only enabled when ``DEBUG`` was
-        ``False``.
-
 ``django.template.loaders.locmem.Loader``
 
 .. class:: locmem.Loader

docs/ref/templates/builtins.txt

@@ -1867,10 +1867,6 @@ This is compatible with a strict Content Security Policy that prohibits in-page
 script execution. It also maintains a clean separation between passive data and
 executable code.
 
-.. versionchanged:: 4.1
-
-    In older versions, the HTML "id" was a required argument.
-
 .. templatefilter:: last
 
 ``last``

docs/ref/urlresolvers.txt

@@ -129,15 +129,11 @@ If the URL does not resolve, the function raises a
 
     .. attribute:: ResolverMatch.captured_kwargs
 
-        .. versionadded:: 4.1
-
         The captured keyword arguments that would be passed to the view
         function, as parsed from the URL.
 
     .. attribute:: ResolverMatch.extra_kwargs
 
-        .. versionadded:: 4.1
-
         The additional keyword arguments that would be passed to the view
         function.
 

docs/ref/utils.txt

@@ -670,10 +670,6 @@ escaping HTML.
     serialize the data. See :ref:`JSON serialization
     <serialization-formats-json>` for more details about this serializer.
 
-    .. versionchanged:: 4.1
-
-        In older versions, the ``element_id`` argument was required.
-
     .. versionchanged:: 4.2
 
         The ``encoder`` argument was added.

docs/ref/validators.txt

@@ -337,8 +337,6 @@ to, or in lieu of custom ``field.clean()`` methods.
 ``StepValueValidator``
 ----------------------
 
-.. versionadded:: 4.1
-
 .. class:: StepValueValidator(limit_value, message=None)
 
     Raises a :exc:`~django.core.exceptions.ValidationError` with a code of

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"):

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``::

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
 =================
 

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
 ==========
 

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

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:

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

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::
 

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.

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.

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

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