Skip to content

Add more clarity about things that cannot be done while working on a bug fix patch #16914

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.

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

Merged
merged 1 commit into from
Jun 27, 2022
Merged
Changes from all commits
Commits
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
15 changes: 12 additions & 3 deletions contributing/code/maintenance.rst
Original file line number Diff line number Diff line change
Expand Up @@ -11,8 +11,6 @@ acceptable changes.
* New unit tests cover the bug fix;
* The current buggy behavior is not widely used as a "feature".

While working on a bug fix, don't refactor the code or introduce new classes.

.. note::

When documentation (or PHPDoc) is not in sync with the code, code behavior
Expand Down Expand Up @@ -46,7 +44,8 @@ a case by case basis:
* **Tests**: Tests that increase the code coverage can be added.

The following changes are **generally not accepted** in a patch version, except
on a case by case basis:
on a case by case basis (mostly when this is related to fixing a security
issue):

* **Performance improvement**: Performance improvement should only be accepted
if the changes are local (located in one class) and only for algorithmic
Expand All @@ -58,6 +57,16 @@ on a case by case basis:
existing code base, if they are not too invasive, and if merging them into
higher branches would not lead to complex branch merging.

* **Adding new classes or non private methods**: While working on a bug fix,
never introduce new classes or public/protected methods (or global
functions).

* **Adding configuration options**: Introducing new configuration options must
never allowed.

* **Adding new deprecations**: After a version reaches stability, new
deprecations cannot be added anymore.

Anything not explicitly listed above should be done on the next minor or major
version instead. For instance, the following changes are never accepted in a
patch version:
Expand Down