Maintenance

During the lifetime of a minor version, new releases (patch versions) are

published on a monthly basis. This document describes the boundaries of

acceptable changes.

**Bug fixes** are accepted under the following conditions:

* The change does not break valid unit tests;

* New unit tests cover the bug fix;

* The current buggy behavior is not widely used as a "feature".

..note::

When documentation (or phpdoc) is not in sync with the code, code behavior

should always be considered as being the correct one.

Besides bug fixes, other minor changes can be accepted in a patch version:

* **Performance improvement**: Performance improvement should only be accepted

if the changes are local (located in one class) and only for algorithmic

issues (any such patches must come with numbers that show a significant

improvement on real-world code);

* **Newer versions of PHP/HHVM**: Fixes that add support for newer versions of

PHP or HHVM are acceptable if they don't break the unit test suite;

* **Translations**: Translation updates and additions are accepted;

* **Version updates for Composer dependencies**: Changing the minimal version

of a dependency is possible, bumping to a major one is not;

* **Coding standard**: Coding standard fixes are not recommended but can be

accepted for consistency with the existing code base, if they are not too

invasive, and if merging them on master would lead to complex branch merging.

Anything not explicitly listed above should be done on the next minor or major

version instead (aka the *master* branch). For instance, the following changes

are never accepted in a patch version:

* **New features**;

* **Backward compatibility breaks**: Note that backward compatibility breaks

can be done when fixing a security issue if it would not be possible to fix

it otherwise;

* **Support for external platforms**: Adding support for new platforms (like

Google App Engine) cannot be done in patch versions;

* **Exception messages**: Exception messages must not be changed as some

automated systems might rely on them (even if this is not recommended);

* **Adding new Composer dependencies**;

* **Support for newer major versions of Composer dependencies**: Taking into

account support for newer versions of an existing dependency is not

acceptable.

Before working on a patch, you must determine on which branch you need to

work:

* ``2.3``, if you are fixing a bug for an existing feature (you may have

to choose a higher branch if the feature you are fixing was introduced

in a later version);

* ``master``, if you are adding a new feature.

* ``2.3``, if you are fixing a bug for an existing feature or want to make a

change that falls into the:doc:`list of acceptable changes in patch versions

</contributing/code/maintenance>` (you may have to choose a higher branch if

the feature you are fixing was introduced in a later version);

* ``master``, if you are adding a new feature.

..note::

be fixed. The end of this period is referenced as being the *end of life* of

a release.

..note::

The:doc:`maintenance document</contributing/code/maintenance>` describes

the boundaries of acceptable changes during maintenance.

Symfony Versions