Improving the Symfony Release Process

December 10, 2015 · Published by Avatar of Javier Eguiluz Javier Eguiluz

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.

Published in #Symfony

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

Avatar of Piotr Łuczko
Piotr Łuczko said on Dec 10, 2015
Good news :)

Also update your site here: http://symfony.com/doc/current/contributing/community/releases.html
Avatar of Javier Eguiluz
Javier Eguiluz Certified said on Dec 10, 2015
@Piotr the changes are ready but not merged yet: https://github.com/symfony/symfony-docs/pull/5994
Avatar of Tomas Votruba
Tomas Votruba said on Dec 10, 2015
This is so pragmatic and easy-going practice. I was amazed by it since 2.8/3.0 and Fabien's talk in Paris and I wonder, why I didn't figure this out earlier.

I just wanna say I love it :)
Avatar of Revelator
Revelator said on Dec 11, 2015
Symfony 4
Avatar of Lynn van der Berg
Lynn van der Berg said on Dec 11, 2015
This is exactly what 2.x was lacking, a consistent releasing system! I'm very glad this has been decided.
Avatar of Radu Murzea
Radu Murzea said on Dec 12, 2015
OK, so the release and end of support dates are as follows:

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...
Avatar of Wouter de Jong
Wouter de Jong said on Dec 12, 2015
With such a strict release plan, I think it's time for Symfony to declare a roadmap as well. Symfony has always been community driven -> new features are based on what the community submits. It seems very strange to have such a very very very strict release schedule, without a clear vision/roadmap on what to include.

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!
Avatar of Alexis Lefebvre
Alexis Lefebvre said on Dec 13, 2015
People who want to use only LTS versions will have to wait for X.4 version to get a new LTS version. They will have to wait 2 years between the releases of LTS, but the next version will come in the same time as the LTS. It seems that these LTS versions will be always outdated, in other words LTS will always be one version behind the master branch. I don't know if it's a good or bad thing.

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?
Avatar of Wouter de Jong
Wouter de Jong said on Dec 13, 2015
@Alexis Lefebvre, as there are no breaking changes between X.0 and X.4, you can consider each X serie as LTS. In other words: If your code works on X.0, it works on X.4 as well.

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.

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.