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!
Nice, what about supporting HHVM?
Great,
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:
This sounds great. Thanks for listening to the community so well.
Shouldn't http://symfony.com/doc/current/contributing/community/releases.html be updated as well?
@Andre, your concerns are very valid. However, I think that the real problem is that it looks like some distributions haven't realized yet that PHP has drastically changed its release process.
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.
@Andre, to be clear 2.7 will still be supported for a year when 3.3 will come out (+ an additional year for security issues.) That's the whole principle of LTS vs standard releases; the bump to 3.x does not impact the continuity of our process.
Recently I ran into some issues when working with Symfony classes related to Sessions. It seems Symfony2 sessions are not fully decoupled from how PHP handles sessions internally. Is this on the radar for 3.x?
@Javier True, but not sure distros are willing to take any risk on this, in the enterprise their whole existence is about providing very stable platforms. It would probably be more fruitful for PHP and Distros alike, for PHP to adapt a LTS strategy like Symfony and eZ Publish has, or at a minimum like Drupal now does with last stable being LTS.
@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.
@Javier what about with HHVM support, it will pass 100% of test too?
Great news!!
@Andre Symfony 2.3 works well with PHP 5.5 and 5.6, so where is the problem, if 3rd party bundles and libraries stop supporting PHP 5.3? PHP 5.3 is end of life, so we should get rid of it. First step is not support it anymore in your project, and if Symfony does bump the php requirement this is a huge success.
Can't wait to see that :)
@Patrik Very few end users use PHP from PHP.net, so "PHP X.Y is end of life" is not a valid argument to them (however might be in the future if people start to use official Docker PHP containers which for good or bad uses packages directly from PHP.net).
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.
Like the first comment says: there's no mention of maintaining maximum compatibility with HHVM (like the current v2.x does). Maybe it should be added to the Milestone on GitHub, if you agree with this.
My professional (Scribe Inc. @ https://github.com/scribenet) and personal (https://github.com/robfrawley) projects are all moving toward a minimum requirement of PHP 5.6 - some of them already have this dependency. While Scribe's main website isn't open-source, many of the components used by it have been broken out into open-source bundles/libraries and will be requiring PHP 5.6 by next year if they don't already.
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.
@Rob, while I do agree with you that it's very simple to roll your own compilled PHP installation, I should remind you that there are a lot of people using shared hosting options and that, because of that, are unable to change their default PHP.
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.
@Pedro, keep in mind that Symfony 3.0 stable is scheduled for Nov 2015, still almost a year from now. PHP 5.4 end-of-life will have passed by then and I expect hosting providers to migrate -at least- to PHP 5.5. Active support will have already ended and noone can argue that 2 years+ availability is not enough for migration.
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.
An instructive post. People to really know who they want to reach and why or else, they'll have no way to know what they're trying to achieve. People need to hear this and have it drilled in their brains.. Thanks for sharing this great article. check for ecommerce tips and solution… http://poweredby247.com
Can't express enough how on point this is. Well considered argument and very positive news all around.