Renamed the "Supported versions" label.

docs/howto/upgrade-version.txt

@@ -8,7 +8,7 @@ version has several benefits:
 * New features and improvements are added.
 * Bugs are fixed.
 * Older version of Django will eventually no longer receive security updates.
-  (see :ref:`backwards-compatibility-policy`).
+  (see :ref:`supported-versions-policy`).
 * Upgrading as each new Django release is available makes future upgrades less
   painful by keeping your code base up to date.
 

docs/internals/contributing/committing-code.txt

@@ -153,8 +153,7 @@ Django's Git repository:
   commit. This goes a *long way* in helping everyone follow your changes.
 
 * Separate bug fixes from feature changes. Bugfixes may need to be backported
-  to the stable branch, according to the :ref:`backwards-compatibility policy
-  <backwards-compatibility-policy>`.
+  to the stable branch, according to :ref:`supported-versions-policy`.
 
 * If your commit closes a ticket in the Django `ticket tracker`_, begin
   your commit message with the text "Fixed #xxxxx", where "xxxxx" is the

docs/internals/release-process.txt

@@ -116,7 +116,7 @@ A more generic example:
   LTS to LTS upgrades).
 * Z.0: Drop deprecation shims added in Y.0 and Y.1.
 
-.. _backwards-compatibility-policy:
+.. _supported-versions-policy:
 
 Supported versions
 ==================

docs/intro/whatsnext.txt

@@ -215,8 +215,8 @@ We follow this policy:
 
 * Documentation fixes and improvements may be backported to the last release
   branch, at the discretion of the committer, however, once a version of
-  Django is :ref:`no longer supported<backwards-compatibility-policy>`, that
-  version of the docs won't get any further updates.
+  Django is :ref:`no longer supported<supported-versions-policy>`, that version
+  of the docs won't get any further updates.
 
 * The `main documentation Web page`_ includes links to documentation for
   previous versions. Be sure you are using the version of the docs