mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-08-03 18:38:50 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Fixed #21188 -- Introduced subclasses for to-be-removed-in-django-XX warnings

Browse source 
Thanks Anssi Kääriäinen for the idea and Simon Charette for the
review.
This commit is contained in:
Claude Paroz 2014-02-26 22:48:20 +01:00
parent 70ec4d776e
commit 210d0489c5
84 changed files with 287 additions and 189 deletions
Download patch file Download diff file Expand all files Collapse all files

10
docs/internals/contributing/writing-code/submitting-patches.txt
View file

@ -173,11 +173,12 @@ There are a couple reasons that code in Django might be deprecated:
As the :ref:`deprecation policy<internal-release-deprecation-policy>` describes,
the first release of Django that deprecates a feature (``A.B``) should raise a
``PendingDeprecationWarning`` when the deprecated feature is invoked. Assuming
``RemovedInDjangoXXWarning`` (where XX is the Django version where the feature
will be removed) when the deprecated feature is invoked. Assuming
we have a good test coverage, these warnings will be shown by the test suite
when :ref:`running it <running-unit-tests>` with warnings enabled:
``python -Wall runtests.py``. This is annoying and the output of the test suite
should remain clean. Thus, when adding a ``PendingDeprecationWarning`` you need
should remain clean. Thus, when adding a ``RemovedInDjangoXXWarning`` you need
to eliminate or silence any warnings generated when running the tests.
The first step is to remove any use of the deprecated behavior by Django itself.
@ -218,9 +219,8 @@ Finally, there are a couple of updates to Django's documentation to make:
under the ``A.B+2`` version describing what code will be removed.
Once you have completed these steps, you are finished with the deprecation.
In each minor release, all ``PendingDeprecationWarning``\s are promoted to
``DeprecationWarning``\s and any features marked with ``DeprecationWarning``
are removed.
In each minor release, all ``RemovedInDjangoXXWarning``\s matching the new
version are removed.
Javascript patches
------------------

13
docs/internals/release-process.txt
View file

@ -58,18 +58,17 @@ security purposes, please see :doc:`our security policies <security>`.
``A.B+2``.
So, for example, if we decided to start the deprecation of a function in
Django 1.5:
Django 1.7:
* Django 1.5 will contain a backwards-compatible replica of the function which
will raise a ``PendingDeprecationWarning``. This warning is silent by
* Django 1.7 will contain a backwards-compatible replica of the function which
will raise a ``RemovedInDjango19Warning``. This warning is silent by
default; you can turn on display of these warnings with the ``-Wd`` option
of Python.
* Django 1.6 will contain the backwards-compatible replica, but the warning
will be promoted to a full-fledged ``DeprecationWarning``. This warning is
*loud* by default, and will likely be quite annoying.
* Django 1.8 will still contain the backwards-compatible replica. This
warning becomes *loud* by default, and will likely be quite annoying.
* Django 1.7 will remove the feature outright.
* Django 1.9 will remove the feature outright.
Micro release
Micro releases (1.5.1, 1.6.2, 1.6.1, etc.) will be issued as needed, often to