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

Thanks Anssi Kääriäinen for the idea and Simon Charette for the
review.

2 files changed, 11 insertions, 12 deletions

diff --git a/docs/internals/contributing/writing-code/submitting-patches.txt b/docs/internals/contributing/writing-code/submitting-patches.txt
index 37354f7a81..4efeab9fc5 100644
--- a/docs/internals/contributing/writing-code/submitting-patches.txt
+++ b/docs/internals/contributing/writing-code/submitting-patches.txt
@@ -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
 ------------------
diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt
index d06dbac954..43d23717fc 100644
--- a/docs/internals/release-process.txt
+++ b/docs/internals/release-process.txt
@@ -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