Removed versionadded/changed annotations for 5.0.

This also removes remaining versionadded/changed annotations for older
versions.

6 files changed, 0 insertions, 65 deletions

diff --git a/docs/ref/models/constraints.txt b/docs/ref/models/constraints.txt
index 6339c39679..7dfc3b7d28 100644
--- a/docs/ref/models/constraints.txt
+++ b/docs/ref/models/constraints.txt
@@ -60,8 +60,6 @@ constraint.
 ``violation_error_code``
 ------------------------
 
-.. versionadded:: 5.0
-
 .. attribute:: BaseConstraint.violation_error_code
 
 The error code used when ``ValidationError`` is raised during
@@ -263,8 +261,6 @@ creates a unique index on ``username`` using ``varchar_pattern_ops``.
 ``nulls_distinct``
 ------------------
 
-.. versionadded:: 5.0
-
 .. attribute:: UniqueConstraint.nulls_distinct
 
 Whether rows containing ``NULL`` values covered by the unique constraint should
@@ -284,8 +280,6 @@ PostgreSQL 15+.
 ``violation_error_code``
 ------------------------
 
-.. versionadded:: 5.0
-
 .. attribute:: UniqueConstraint.violation_error_code
 
 The error code used when ``ValidationError`` is raised during
diff --git a/docs/ref/models/database-functions.txt b/docs/ref/models/database-functions.txt
index 1dc0ce4e97..eb08e160f7 100644
--- a/docs/ref/models/database-functions.txt
+++ b/docs/ref/models/database-functions.txt
@@ -569,11 +569,6 @@ Usage example:
     On Oracle, the SQL ``LOCALTIMESTAMP`` is used to avoid issues with casting
     ``CURRENT_TIMESTAMP`` to ``DateTimeField``.
 
-.. versionchanged:: 5.0
-
-    In older versions, the SQL ``CURRENT_TIMESTAMP`` was used on Oracle instead
-    of ``LOCALTIMESTAMP``.
-
 ``Trunc``
 ---------
 
diff --git a/docs/ref/models/expressions.txt b/docs/ref/models/expressions.txt
index f630142294..1b6a208d01 100644
--- a/docs/ref/models/expressions.txt
+++ b/docs/ref/models/expressions.txt
@@ -1053,8 +1053,6 @@ calling the appropriate methods on the wrapped expression.
 
     .. attribute:: allowed_default
 
-        .. versionadded:: 5.0
-
         Tells Django that this expression can be used in
         :attr:`Field.db_default`. Defaults to ``False``.
 
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index ba46726ab8..fa19f58c54 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -138,10 +138,6 @@ the choices are:
   provide a well-known inventory of values, such as currencies, countries,
   languages, time zones, etc.
 
-.. versionchanged:: 5.0
-
-    Support for mappings and callables was added.
-
 Generally, it's best to define choices inside a model class, and to
 define a suitably-named constant for each value::
 
@@ -372,10 +368,6 @@ There are some additional caveats to be aware of:
 
         __empty__ = _("(Unknown)")
 
-.. versionchanged:: 5.0
-
-    Support for using enumeration types directly in the ``choices`` was added.
-
 ``db_column``
 -------------
 
@@ -405,8 +397,6 @@ looking at your Django code. For example::
 ``db_default``
 --------------
 
-.. versionadded:: 5.0
-
 .. attribute:: Field.db_default
 
 The database-computed default value for this field. This can be a literal value
@@ -1235,8 +1225,6 @@ when :attr:`~django.forms.Field.localize` is ``False`` or
 ``GeneratedField``
 ------------------
 
-.. versionadded:: 5.0
-
 .. class:: GeneratedField(expression, output_field, db_persist=None, **kwargs)
 
 A field that is always computed based on other fields in the model. This field
diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt
index b203ff67c4..65ed4924f7 100644
--- a/docs/ref/models/instances.txt
+++ b/docs/ref/models/instances.txt
@@ -580,10 +580,6 @@ which returns ``NULL``. In such cases it is possible to revert to the old
 algorithm by setting the :attr:`~django.db.models.Options.select_on_save`
 option to ``True``.
 
-.. versionchanged:: 5.0
-
-    The ``Field.db_default`` parameter was added.
-
 .. _ref-models-force-insert:
 
 Forcing an INSERT or UPDATE
@@ -616,11 +612,6 @@ only.
 
 Using ``update_fields`` will force an update similarly to ``force_update``.
 
-.. versionchanged:: 5.0
-
-    Support for passing a tuple of parent classes to ``force_insert`` was
-    added.
-
 .. _ref-models-field-updates-using-f-expressions:
 
 Updating attributes based on existing fields
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
index 3f9e90da20..7a0d086bfe 100644
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -1160,12 +1160,6 @@ supports prefetching of
 queryset for each ``ContentType`` must be provided in the ``querysets``
 parameter of :class:`~django.contrib.contenttypes.prefetch.GenericPrefetch`.
 
-.. versionchanged:: 5.0
-
-    Support for prefetching
-    :class:`~django.contrib.contenttypes.fields.GenericForeignKey` with
-    non-homogeneous set of results was added.
-
 For example, suppose you have these models::
 
     from django.db import models
@@ -2114,13 +2108,6 @@ SQL equivalent:
             2
         )
 
-    .. versionchanged:: 5.0
-
-        In older versions, on databases without native support for the SQL
-        ``XOR`` operator, ``XOR`` returned rows that were matched by exactly
-        one operand. The previous behavior was not consistent with MySQL,
-        MariaDB, and Python behavior.
-
 Methods that do not return ``QuerySet``\s
 -----------------------------------------
 
@@ -2402,10 +2389,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:: 5.0
-
-    The ``create_defaults`` argument was added.
-
 ``bulk_create()``
 ~~~~~~~~~~~~~~~~~
 
@@ -2470,11 +2453,6 @@ be in conflict must be provided.
 Enabling the ``ignore_conflicts`` parameter disables setting the primary key on
 each model instance (if the database normally supports it).
 
-.. versionchanged:: 5.0
-
-    In older versions, enabling the ``update_conflicts`` parameter prevented
-    setting the primary key on each model instance.
-
 .. warning::
 
     On MySQL and MariaDB, setting the ``ignore_conflicts`` parameter to
@@ -2629,11 +2607,6 @@ evaluated will force it to evaluate again, repeating the query.
 long as ``chunk_size`` is given. Larger values will necessitate fewer queries
 to accomplish the prefetching at the cost of greater memory usage.
 
-.. versionchanged:: 5.0
-
-    Support for ``aiterator()`` with previous calls to ``prefetch_related()``
-    was added.
-
 On some databases (e.g. Oracle, `SQLite
 <https://www.sqlite.org/limits.html#max_variable_number>`_), the maximum number
 of terms in an SQL ``IN`` clause might be limited. Hence values below this
@@ -4162,10 +4135,6 @@ When using multiple databases with ``prefetch_related_objects``, the prefetch
 query will use the database associated with the model instance. This can be
 overridden by using a custom queryset in a related lookup.
 
-.. versionchanged:: 5.0
-
-    ``aprefetch_related_objects()`` function was added.
-
 ``FilteredRelation()`` objects
 ------------------------------