Improving the Symfony Release Process

The Symfony Release Process is arguably one of the best selling points of the Symfony project. Thanks to our predictable and transparent process, companies can plan years in ahead their Symfony integration.
The recent launch of Symfony 2.8, which will be the last minor version of the 2.x branch, made us think about further tweaks in the release process. That's why during his past SymfonyCon Paris 2015 keynote, Fabien Potencier announced the new Symfony release process.
These are the main changes introduced starting from 3.0 version:
- Each major version (3.x, 4.x) will publish five minor versions (X.0, X.1, X.2, X.3 and X.4).
- All minor versions are standard versions (8 months of support) except the last one (X.4) which is a long term support version (36 months of support).
- Major versions are released at the same time of the last minor version of the previous branch (e.g. 4.0.0 and 3.4.0 are released simultaneously).
Thanks to our strict deprecation policy this release process is possible and ensures a smooth upgrade between different Symfony versions.
This new process means that Symfony 4 will be released on November 2017. Check out the details of any past, present or future Symfony version in our updated Symfony version checker. You can also subscribe for free to our notification service to receive an email announcing each Symfony release.
Help the Symfony project!
As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.
Comments
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.
Also update your site here: http://symfony.com/doc/current/contributing/community/releases.html
I just wanna say I love it :)
2.3: May 2013 - May 2017
2.7: May 2015 - May 2019
2.8: Nov 2015 - Nov 2019
3.0: Nov 2015 - Jan 2017
3.1: May 2016 - Jul 2017
3.2: Nov 2016 - Jan 2018
3.3: May 2017 - Jul 2018
3.4: Nov 2017 - Nov 2021
4.0: Nov 2017 - Jan 2019
4.1: May 2018 - Jul 2019
It seems versions are released faster than how the old ones are abandoned.
So for example, when you are in January 2017, you'll have to offer simultaneous support for 2.3, 2.7, 2.8, 3.0, 3.1 and 3.2. That's six (!!) versions of Symfony, from 2 different generations.
A more extreme example is in December 2017, when you'll have to offer simultaneous support for 2.7, 2.8, 3.2, 3.3, 3.4 and 4.0. As you can see there are just as many, but this example is more extreme because you now support 3 (!!) different Symfony framework generations (2.x, 3.x and 4.x) at the same time.
All these minor and major versions have many differences between them and both seasoned contributors and core team members can get confused about what feature is where, what feature was deprecated when, in what branch to merge what pull-requests and so on.
It can become quite overwhelming, which will for sure increase the number of mistakes and/or bugs.
Do you have any concrete plans on how to deal with all this increased scope and risk ?
Personally, I recommend taking this seriously because otherwise it will bite you in the ass...
Adding a roadmap doesn't mean community can add features they like. But at least, as the core team, you can work towards a main goal for each release. That way, you know you have something nice each release and you know it's time for a new major after 3.4. At the moment, you can just guess (what if Symfony becomes so stable that there is not much more to change after 4.3?).
Besides that, having a roadmap makes things clearer for users as well. At the moment, they can only base on one thing: The next release probably is not going to be worse than the current one.
Anyway, I love the fact that mid-major LTS versions are removed, they did no longer make sense with the BC promise!
Will the future LTS versions will benefit from improvements from the next major version which don't break BC or will they only receive security updates?
This means that a company that supports Symfony 3 now can have the latest features for 2 years (3.0, 3.1, 3.2, 3.3, 3.4). After these 2 years, they can work on making the code base compatible for Symfony 4 (which can be done in 3.4 by removing all usages of deprecated features). They have 3 years to do this, after this time 3.4 will reach end of maintance. At any moment during this phase, if the code works without deprecation notices in 3.4 they can safely update to the latest 4.y release. Then, everything starts again.