Make addressing deprecations acceptable in a patch release

Addressing a deprecation is not a bugfix, it does not make the software
more stable. Deprecations are annoying though, and unless we switch to
using the ~ operator instead of the ^ operator for our dependencies, we
might get new ones out of the blue.
I propose to explicitly allow PRs that address deprecations in patch
releases, so that users do not have to wait until the next minor to have
fewer deprecations.

Author: greg0ire

source/contribute.rst

@@ -113,6 +113,7 @@ With that in mind, things that can go on the patch release branch
 include:
 
 - bugfixes;
+- addressing deprecations from dependencies;
 - adding tests, especially for bugs that were fixed;
 - updates, corrections or improvements to non-code assets like
   documentation, build scripts or tooling configuration;
@@ -125,6 +126,12 @@ include:
    When phpdoc comments are imprecise but not wrong technically, target
    the next minor release branch instead.
 
+.. note::
+   When addressing a deprecation notice from a dependency, make sure not
+   to bump any version constraint, so as to keep the patch release
+   obtainable without upgrading any other dependencies. You may use
+   feature detection (calls to ``class_exists()`` and such) to do so.
+
 The next minor version branch may include:
 
 - refactorings, unless they are necessary for a bugfix. This is to avoid