Black Friday 2022 Offers 30% discount in SymfonyInsight yearly business plan (offer ends in 3 days)

Experimental Features

Edit this page

Warning: You are browsing the documentation for Symfony 4.4, which is no longer maintained.

Read the updated version of this page for Symfony 6.2 (the current stable version).

Experimental Features

All Symfony features benefit from our Backward Compatibility Promise to give developers the confidence to upgrade to new versions safely and more often.

But sometimes, a new feature is controversial or you cannot find a convincing API. In such cases, we prefer to gather feedback from real-world usage, adapt the API, or remove it altogether. Doing so is not possible with a no BC-break approach.

To avoid being bound to our backward compatibility promise, such features can be marked as experimental and their classes and methods must be marked with the @experimental tag.

A feature can be marked as being experimental for only one minor version, and can never be introduced in an LTS version. The core team can decide to extend the experimental period for another minor version on a case by case basis.

To ease upgrading projects using experimental features, the changelog must explain backward incompatible changes and explain how to upgrade code.

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.