The Release Process
This document explains the Symfony release process (Symfony being the code hosted on the main symfony/symfony Git repository).
Symfony manages its releases through a time-based model; a new Symfony release comes out every six months: one in May and one in November.
This release process has been adopted as of Symfony 2.2, and all the "rules" explained in this document must be strictly followed as of Symfony 2.4.
The six-months period is divided into two phases:
- Development: Four months to add new features and to enhance existing ones;
- Stabilisation: Two months to fix bugs, prepare the release, and wait for the whole Symfony ecosystem (third-party libraries, bundles, and projects using Symfony) to catch up.
During the development phase, any new feature can be reverted if it won't be finished in time or if it won't be stable enough to be included in the current final release.
Each Symfony version is maintained for a fix period of time, depending on the type of the release.
A standard release is maintained for an eight months period.
Long Term Support Releases
Every two years, a new Long Term Support Release (aka LTS release) is published. Each LTS release is supported for a three year period.
Paid support after the three year support provided by the community can also be bought from SensioLabs.
Below is the schedule for the first few versions that use this release model:
- (special) Symfony 2.2 will be released at the end of February 2013;
- (special) Symfony 2.3 (the first LTS) will be released at the end of Mai 2013;
- Symfony 2.4 will be released at the end of November 2013;
- Symfony 2.5 will be released at the end of Mai 2014;
After the release of Symfony 2.3, backward compatibility will be kept at all cost. If it is not possible, the feature, the enhancement, or the bug fix will be scheduled for the next major version: Symfony 3.0.
The work on Symfony 3.0 will start whenever enough major features breaking backward compatibility are waiting on the todo-list.
This release process was adopted to give more predictability and transparency. Is was discussed based on the following goals:
- Shorten the release cycle (allow developers to benefit from the new features faster);
- Give more visibility to the developers using the framework and Open-Source projects using Symfony;
- Improve the experience of Symfony core contributors: everyone knows when a feature might be available in Symfony.
- Coordinate the Symfony timeline with popular PHP projects that work well with Symfony and with projects using Symfony;
- Give time to the Symfony ecosystem to catch up with the new versions (bundle authors, documentation writers, translators, ...).
The six month period was chosen as two releases fit in a year. It also gives plenty of time to work on new features and it also allows for non-ready features to be postponed to the next version without having to wait too much for the next cycle.
The dual maintenance mode was adopted to make every Symfony user happy. Fast movers, who want to work with the latest and the greatest, use the standard releases: a new version is published every six months, and there is a two months period to upgrade. Companies wanting more stability use the LTS releases: a new version is published every two years and there is a year to upgrade.