Why will Symfony 2.0 finally use PHP 5.3?
The framework shootout
As you might know, I'm back from the 2009 Zend Conference. I have already blogged about the conference, but I intentionally forgot to talk about the framework shootout. That's because I felt the need to think about the feedback I had during and after the session, and I wanted to mature my reflection with the Symfony core team before going further into the discussion.
Instead of a classic closing keynote, the Zend Conference ended with a framework shootout. Several frameworks were represented on stage, mostly by their lead developer, and the audience were given the opportunity to ask any question they wanted. One of them was about PHP 5.3 and how each framework will make the transition to this latest and greatest PHP version.
Will Symfony 2.0 be compatible with PHP 5.2?
Both the upcoming Zend Framework and CakePHP 2.0 versions will rely on PHP 5.3. And for Symfony, I said it will still be compatible with PHP 5.2. From my point of view at the time, it would be a mistake to upgrade major frameworks to PHP 5.3 now for one main reason: major frameworks are used by many big companies, and upgrading to the latest version of a software fast in such companies is not always feasible. Sensio works for a lot of them, and we know what we are talking about. And no, some of our customers cannot "simply" compile their own version, because they rely on standard Linux distributions and their associated professional support; or because they have hundreds of machines and don't want to install a specific version of PHP just for some projects. If you attended the keynote, don't feel angry yet, keep reading.
Apparently, many people were quite disappointed with this decision, so I started to think about this matter again. I made the decision to still support PHP 5.2 for Symfony 2.0 almost a year and a half ago. At that time, it was obviously out of question to only support PHP 5.3 and I thought Symfony 2.0 was right around the corner. Time flies and Symfony 2.0 is far from being ready.
So, given that PHP 5.3 is now stable and released, and given that Symfony 2.0 is definitely not right around the corner (probably for late 2010), does it still make sense to continue supporting PHP 5.2? Or do we need to reconsider my decision?
As hinted in this post title, the Symfony core team has changed its mind, and Symfony 2.0 will leverage PHP 5.3 and drop PHP 5.2 compatibility. I hope some of you feel better now, but I can already hear some others starting to grumble. Bear with us, as this decision was not made overnight. Keep reading this post to understand the reasoning behind this decision.
Symfony 2.0 on PHP 5.3: A better language
From a technical standpoint, using PHP 5.3 for Symfony 2.0 is great news. First, because the language has evolved and sports a lot of new exciting features like namespaces, closures, anonymous functions, late static binding, SPL enhancements, better Windows support, and much more. PHP 5.3 is also the fastest PHP release ever, which is a great benefit for complex beasts like frameworks.
Symfony 2.0 on PHP 5.3: Better tools
PHP 5.3 is also about a new ecosystem. The tools are getting better. The old PEAR installer (the one used to manage symfony plugins) is being phased out and replaced with Pyrus, a modern and robust software installer. Symfony 2.0 will definitely be able to leverage this new tool and take advantage of the native phar support to provide simple and better plugin management tools.
Speaking of tools and third party libraries, let's talk about those we use natively in Symfony.
First, our beloved Doctrine ORM. As announced some time ago, Doctrine 2.0 will be only compatible with PHP 5.3. And man, Doctrine 2.0 is gorgeous. Doctrine 2.0 is one of best things that's happened to PHP in a long time.
Then, there is the Zend Framework. Symfony does not rely on the Zend Framework for its core features, but a large number of Symfony developers use some Zend Framework components in their Symfony projects (to add a search engine, connect to some well-known web services, create PDF documents on the fly, ...). Of course, using the new Zend Framework 2.0 components will require that we share the same requirements.
Using PHP 5.3 is about having a better integration with the next generation of frameworks, tools, and third-party libraries out of the box.
Symfony 2.0 on PHP 5.3: Helping the community
Last but not the least, it is also about helping the PHP community. Symfony was one of the first frameworks to join the "Go PHP5" initiative some years ago when the community tried to help people adopting PHP5 faster.
The adoption rate problem is probably what made our decision much more easier to make. As some people said on Twitter and during the keynote, if all major PHP frameworks and libraries start using PHP 5.3 for their next major version, Linux distributions, third-party tools (IDEs, ...), and companies will probably need to embrace the new version faster. And if Symfony can help in this effort, we would be very happy.
Of course, we won't change Redhat's plans overnight. They have a quite strict roadmap, and because of their long-term support, they won't upgrade to the latest PHP version anytime soon; but if some companies use one of these conservative Linux distributions, they will also be conservative with the version of the framework they use. The good news for these companies is that symfony 1.4 will be maintained for three full years (see below).
The Linux distribution problem is also mitigated by the native support of PHP 5.3 in the upcoming Zend Server. If companies are serious about PHP support, they can also switch to the Zend Server and have support for PHP 5.3 out of the box.
Symfony 2.0 on PHP 5.3: Backward compatibility
As Symfony 2.0 is about breaking backward compatibility anyway, the Symfony core team thinks that it is better to break backward compatibility once and for all and avoid yet another major compatibility break in coming years in order to finally support PHP 5.3.
Switching to PHP 5.3 means dropping PHP 5.2 support by embracing PHP 5.3 new
features like namespaces. It means that all Symfony libraries (from the MVC
framework to the Symfony components) will require some drastic changes like
renaming every class (renaming
instance; say good bye to the good old
sf prefix!). For components we have
already published, like the dependency injection container, we will soon
create a 1.0 branch and release a 1.0 version. Then, the trunk will start a
new life and be migrated to PHP 5.3.
But we definitely don't want to loose people who won't be able to upgrade to PHP 5.3. And Symfony is in a very good position to cope with this drastic change, thanks to its Long Term Support (LTS) releases. Symfony 1.4, to be released by the end of this year, is our upcoming LTS release. As any Symfony LTS release, it will be maintained for three years by the Symfony core team. In concrete terms, developers using this version will have support until early 2013. That's plenty of time for projects which cannot afford migrating to PHP 5.3 yet. And keep in mind that the maintenance covers forward compatibility with newer PHP versions. Symfony 1.3/1.4 already works on PHP 5.3.0, and will work on upcoming 5.3.X minor releases.
To sum up, we have decided to take the best of both worlds:
symfony 1.4 (with support until early 2013) will be the best version for existing projects and conservative companies.
Symfony 2.0 (probably to be released late 2010) will be the best version for new projects and companies willing to either install PHP 5.3, use the Zend Server, or install the "right" Linux distribution.
I hope you will all understand and approve this move. The Symfony core team is really excited about the opportunities it gives us, and we think the Symfony 2.0 release will be a blast. Wish us luck!
Thanks to Kris Wallsmith, Fabian Lange, Jonathan Wage, Dustin Whittle, and Stefan Koopmanschap, members of the Symfony core team, who helped me to thoroughly mature my decision and for reviewing this blog post.
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.