PHP 5.3 has been out now for eight months, and in that time lots of projects have made decisions to begin developing against this version of PHP. Juozas Kaziukenas makes the argument that you shouldn’t be afraid of PHP 5.3 and he provides a number of excellent points to support his argument.
I don’t dispute that PHP 5.3 is faster, better, cleaner, and more feature-rich than previous versions. In fact, I’m thrilled to develop for myself on PHP 5.3 and even released a guide for installing it on Ubuntu because the Ubuntu package managers didn’t put it in for the last release.
But when it comes to open source projects endorsing PHP 5.3 as their one and only PHP platform, I encourage caution.
When it comes to open source projects that use PHP, there are three main issues that I believe should be considered before making the leap to PHP 5.3 (or any new release of any new software).
First and foremost, it comes down to how much control you or your users have over their environment. Frameworks like Zend and ORMs like Doctrine can get away with switching to PHP 5.3 because for the most part, their users are power users who will switch to the latest version of PHP to get the latest and greatest features of these products. But for certain open source projects (WordPress springs to mind), the users may either not control their platform or be technologically unable to understand the needs of a new version of PHP. While WordPress is often attacked for being PHP 4.x-compliant, large portions of their detractors forget that WordPress supports a user base that would make any of us jealous; the same thing goes for any project that has any sort of widespread adoption, especially by less-than-technical users.
The second consideration I believe needs to be made is whether or not the new features gained is worth the break in backwards compatibility. Zend, Doctrine and Symfony have all announced that PHP 5.3 will be their base for the next major release – thus reducing the issues related to backwards compatibility. Since you expect major breaks in major releases, it’s easier to break that compatibility and require a new version of PHP. That said, it would be foolish for any open source project to require the latest version of PHP in a minor release, if it was not already required for the last major revision.
Third, anyone planning to require the latest version of PHP, even for a major compatibility break, should consider whether or not they are prepared to continue to support the previous release for some time. Even PHP’s developers still continue to make maintenance releases to PHP 5.2.x, the most recent being February 25th. They continue to do this because there is a considerable amount of legacy code written on the PHP 5.2.x platform, and it would be a significant blow if they simply stopped development on that branch.
There are a great number of features in PHP 5.3 that should be considered and used. Ultimately, I believe that widespread adoption of PHP 5.3 will occur, if it hasn’t already; I’m personally excited about the new and innovative components in it. But switching from one version of PHP to another without careful planning will ultimately damage the credibility and usefulness of a software project, and shouldn’t be a small undertaking.
Frustrated with your company’s development practices?
You don't have to be!
No matter what the issues are, they can be fixed. You can begin to shed light on these issues with my handy checklist.
Plus, I'll help you with strategies to approach the issues at the organization level and "punch above your weight."