Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Make addressing deprecations acceptable in a patch release #485

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Make addressing deprecations acceptable in a patch release #485

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
372a338
Make addressing deprecations acceptable in a patch release
greg0ire Jun 1, 2023
626b235
Document when bumping deps is allowed
greg0ire Jun 1, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions source/contribute.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -113,22 +113,33 @@ 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;
- fixes to incorrect phpdoc comments (docblock type declarations, etc.);
- updates, corrections or improvements to code comments that are not
phpdoc comments;
- _development_ dependency bumps (regular dependencies should not be
bumped).

.. note::

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
unnecessary risks.
- dependency bumps if they lead to code simplifications;
- new deprecations - read our :ref:`Dedicated policy
<./policies/deprecation>` to figure out
how to contribute those.
Expand Down