Symfony 3.0: The roadmap
November 11, 2014
•
Published by
Fabien Potencier
During the last year, I've been talking about Symfony 3.0 at various conferences. I've been thinking about the best Symfony 3.0 strategy for quite a long time now and it's time to share my thoughts with everyone.
Major Versions
Some developers and most project managers are afraid when major versions of their favourite Open-Source libraries are announced; probably because major versions are associated with backward incompatible changes. Many questions arise: Will the changes bring significant value for my project? Is the roadmap clear enough to anticipate the upgrade? Will it be easy/possible to upgrade? What if I don't want or cannot upgrade now? And then some more.
The fear of major new versions is based on bad experiences from the past: think about Perl 6 or PHP 6. In the Symfony world, Symfony 2 was also a big revolution as it is very different from symfony 1. I realise that talking about Symfony 3 makes people nervous and this post is going to explain the Symfony 3 strategy and the reasons why you should not panic.
First, everyone knows that major versions need to happen on a regular basis. We need to be able to break backward compatibility to remove obsolete features, fix architecture mistakes, and take into account the changes in the ecosystem: PHP's new capabilities, best practice changes, new web paradigms, ... The Internet evolves at a very fast pace and if we cannot adapt Symfony fast enough, it will become irrelevant faster than you can imagine.
As the project manager of Symfony, one of my responsibility is it to keep the code as stable as possible for as long as possible. But stability does not mean status quo: we do add new features and we do fix architecture mistakes in minor versions as you can see for yourself in Symfony 2.4, 2.5, and 2.6. All those versions come with major new features and each of them is a great step forward for the framework. But upgrading is very easy because backward compatibility is keptwith older versions. The challenge is the maintenance of the backward compatibility layer for obsolete or deprecated features (and I'm not even talking about the performance penalty we need to minimize.) It has been quite easy for Symfony2 as it is based on a very solid foundation made of decoupled components. By the definition of semantic versioning, a new major version is "just" a milestone where we can clean things up and get rid of the cruft.
What is Symfony 3.0?
Because new features are added all the time in minor versions and because some others are deprecated, you can start to make your code "more compatible" with 3.0 today. Read the upgrade guide for Symfony 3.0 and make the optional suggested changes; that allows you to plan the migration ahead of time at your own pace.
As you might have guessed by now, Symfony 3.0 is not going to be a revolution and the low-level architecture of the framework won't change. Here are some simple examples of changes we made in Symfony 2.x that will make Symfony 3.0 better:
Symfony 3.0 is more standard (usage of PSR-3 for logging and the removal of the
Symfony\Component\HttpKernel\Log\LoggerInterfaceinterface, ...)Symfony 3.0 fixes some architecture mistakes (stateful console helpers are removed in favour of better alternatives (ProgressBar vs ProgressHelper or Table vs TableHelper; Yaml::parse() does not support file names anymore, ...)
Symfony 3.0 is more decoupled and more reusable than ever (the HttpKernel is going to be split into several smaller ones -- the profiler for instance will be standalone; classes are moved from bundles to components; components are extracted from existing ones, ...)
The Symfony 3.0 Schedule
Avoiding the drama about new major versions is also made easier by communicating often and early. That's why the Symfony community has been hard at work to document our strategy: From the backward compatibility promise to the version roadmap and LTS releases.
One way to minimize the impact of new versions is to also make them predictable. According to our roadmap, Symfony 2.7, to be released in May 2015, will be the next long term support release, 2.7 will be maintained until May 2018 for bug fixes and May 2019 for security ones. Instead of planning a 2.8 after 2.7, I propose to make the jump straight to 3.0. So, Symfony 3.0 will be released in November 2015 and the first 3.x long term release will be 3.3 to be released in May 2017.
The interactive Symfony Roadmap has been updated to take the Symfony 3.x branch into account.
What should you do? As explained in the release process documentation chapter, there are two upgrade strategies:
"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 version: a new version is published every six months, and there is a two months period to upgrade. Companies wanting more stability use the LTS versions: a new version is published every two years and there is a year to upgrade."
Where is Symfony 3.0?
To make it easy for everyone to start contributing to Symfony 3.0 today, the master branch of the main repository now hosts the Symfony 3.0 code; a 2.6 and a 2.7 branches have been created for these upcoming versions.
If your project is using the Symfony master branch to follow the latest 2.x evolutions, consider switching to the 2.7 branch today.
The merge strategy will be almost the same as it is currently, with some slight differences:
New features will be merged in 2.7 if they do not break backward compatibility or if they do not impact existing code;
New features will only be merged in 3.0 if there is no way to make them work in the 2.7 branch;
Bug fixes will still be merged in the oldest and still maintained branch and will be merged back to newer versions on a regular basis, including the master (aka 3.0) branch.
Symfony 3.0 minimal PHP version
Last, but not the least, what about the minimum version of PHP for Symfony 3.0? I started a poll on this topic a few days ago and here are the results:
| Version | Votes | % |
|---|---|---|
| 5.3.3 | 31 | 2% |
| 5.3.x | 56 | 3% |
| 5.4.x | 260 | 16% |
| 5.5.x | 568 | 35% |
| 5.6.x | 495 | 30% |
| 7.x | 225 | 14% |
Based on these results, I propose to make PHP 5.5 the minimum PHP version required for Symfony 3.0. I want to keep the possibility to bump to PHP 5.6 sometime next year based on our needs and on the most popular PHP versions used by hosting companies and Linux distributions.
How can you help?
There are a lot of easy changes that can to be done for Symfony 3.0 today. First, all deprecated features need to generate deprecated logs in the 2.7 branch (like what we did before the 2.3 release.) Then, everything deprecated must be removed in the master branch. Finally, the upgrade guide should be tested and augmented to make the upgrade process as easy as possible for everyone. You can also have a look at the issues specifically tagged as 3.0 on Github.
Happy Coding!
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 are closed.
To ensure that comments stay relevant, they are closed for old posts.
Looks to be a steady step forward for Symfony.
Regarding PHP requirements, while I technically like that this will push the ecosystem to PHP 5.5 as a baseline, there are two concerns:
- RHEL/CentOs/Oracle-/Amazone-Linux 7 is at PHP 5.4 (the main package, the long term supported one), and while Redhat might be convinced to upgrade the main package in the first 3 years in a minor release of as stated life cycle page*, they have afaik never done that, so it will most likely not change before v8.0 around end of 2017 (and then hosting companies takes a year or two to upgrade often)
- There is a risk that a lot of third party bundles & libraries stop supporting PHP 5.3 and ultimately users of Symfony 2.3/2.7, so there should maybe be a clear recommendation to community to continue to support (test,accept changes,maintain) Symfony 2.3/2.7 at least until 3.3 is out
* https://access.redhat.com/support/policy/updates/errata
Shouldn't http://symfony.com/doc/current/contributing/community/releases.html be updated as well?
In the past, PHP released few versions every three or four years: 5.2.0 (2006), 5.3.0 (2009), 5.4.0 (2012). At that time it was OK if the distributions took some time before upgrading PHP versions, because the changes were massive.
However, recently PHP has switched to much more frequent releases: 5.5.0 (2013), 5.6.0 (2014), 7.0 (expected 2015). Linux distributions (and some PHP developers) should understand that PHP now releases a major version every year and therefore, is unacceptable to wait 4 or 5 years before upgrading the PHP version.
@Fabien Yes, I'm aware of that, was not talking about Symfony itself which is flawless on this. Rather third party bundles and php libraries. It's just about making sure these projects also continuing to maintain versions that works with Symfony 2.3 and PHP 5.3, and not jump ship to PHP 5.5.
@cameron: This is probably because Symfony takes advantage of internal PHP SessionInterface on PHP 5.4 and higher, this should not affect you if you use the Session API as opposed to using internal handlers directly. But yes this will likely be fixed in 3.0.
Today most use PHP from distros, and the distros maintain a specific PHP version with security & some bug fixes backported. In other words extremely stable, no regressions like you sometimes get from PHP.net releases. So if you sell software and offer long term contracts, you're typically locked in on PHP 5.3.3-rhel-patch-x on any contracts you did earlier this year with rhel/centos 6.x customers for the next 3+ years.
However there is nothing to discuss here, I'm not against Symfony pushing PHP requirement to 5.5 from a developer perspective, I was just voicing a concern on thrid party libraries / bundles from a business perspective.
Why have we made this decision? As the Systems Architect for Scribe Inc., my focus is stability, security, and speed for our clients. Running an older version of PHP is counter to these goals. The largest gripe of mine has been increased memory usage with each subsequent PHP release, but with the cost of memory constantly dropping this is of less and less concern. The interpreter might use more memory, but (even with the addition of new constructs and features) has consistently included speed improvements and optimizations. Security wise, I find running newer software lowers the margin for exploits.
As for those running stock distribution packages on long-term distribution releases, it's simple enough to roll your own compiled PHP installation. Many common distributions have well-maintained external packages of the newer PHP releases. At Scribe, we run our own custom-compiled Nginx server with community-build, latest-release PHP packages. This is the case with many of the software we use. I find the open-source community to be much more responsive to bugs/security issues than any contract with a Linux vendor. Assuming you know some C, go ahead and fix the issue yourself and contribute it upstream if need be.
Regardless, Symfony should not be bound by a distribution's opinion that consistency of a package version somehow equates to increased stability, as that is simply not the case. Given adequate knowledge, testing, and common-sense, it is easy to run the latest and greatest PHP version on any platform.
With that rant out of the way, I'm excited to see that you are considering PHP 5.5 as the minimum version for Symfony 3, but given the first LTS release (3.3) will be supported through May 2021 (and given the assumption that no minor 3.x release will increase this minimum version requirement) I think the benefits of many of the new features and constructs in 5.6 warrant sincere consideration as the minimum requirement for Symfony 3.
The addition of importing constants and functions via the "use" construct alone could be highly beneficial. Variadic function support is amazing and makes dynamic function parameter counts so much cleaner than previously---it has been a *long* time coming (while I primarily develop using PHP for our web application, we also use Ruby for some internal services that the front-end is dependent on and I'm excited to see PHP embrace some of the great features of other languages like Ruby's "splat" syntax). The SSL/TLS improvements are welcome. And important for our services, it uses the "default_charset" more intelligently for function calls.
Lastly, I'll say that in my opinion, PHP 5.5 should be the *minimum possibility* for Symfony 3's requirement.
That would make adopting Symfony in widely used projects (like phpBB, which uses a lot of Symfony componentes) prohibitive, seeing most shared hosting options are NOT compatible with PHP 5.5. Dreamhost uses 5.4.
From a developer-perspective, I would even vouch for PHP 5.6, but I have to admit that for some vendors or support contractors, PHP is not in focus, so migration can take more than a whole year.
Thanks for sharing this great article.
check for ecommerce tips and solution… http://poweredby247.com