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/async.txt | 2 -- docs/topics/class-based-views/index.txt | 2 -- docs/topics/db/queries.txt | 12 ------------ docs/topics/db/transactions.txt | 5 ----- docs/topics/forms/formsets.txt | 12 ------------ docs/topics/forms/index.txt | 9 --------- docs/topics/forms/media.txt | 7 ------- docs/topics/forms/modelforms.txt | 2 -- docs/topics/migrations.txt | 2 -- docs/topics/signing.txt | 12 ------------ docs/topics/testing/overview.txt | 4 ---- docs/topics/testing/tools.txt | 13 ------------- 12 files changed, 82 deletions(-) (limited to 'docs/topics') 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 ` 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 ```` tag in place of ``