Upgrades In Open Source

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.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

John Kary (@johnkary) wrote at 3/8/2010 8:51 am:

I think your approach to this from an open-source angle is interesting, because it really applies to everyone in software development: both open and closed-source. I think of a company like Adobe, which rarely issues bug/exploit patches for old versions of their software. They have no LTS (Long Term Support) version for their software; it’s whatever version was last released. Think of Adobe’s install base for something like Acrobat Reader or Photoshop. Do they not issue a LTS release because it might hurt business? Why not just require users to upgrade to stay current?

Related to your first point about WordPress, is WordPress in the same boat as Microsoft was with IE6? Are we going to see a 6-year drought between any real progress or an increase in minimum recommendations just because their user base is “too big to fail?” Not making a necessary change because it would affect too many people is like not ending a marriage because it would hurt too many other people.

This “getting away with” requiring PHP 5.3 is hot air. If anything, the next version of WordPress SHOULD require a modern PHP version so it can lend itself to modern best practices and enhanced security. Being such a widely used application, that alone should be paramount. If the core WordPress developers started on a new version of WordPress requiring PHP 5.3, by the time it’s done, 5.3 might have more adoption. This is exactly the mindset of major framework developers for symfony and Zend Framework.

Chris (@dragonmantank) wrote at 3/8/2010 8:59 am:

There is actually two problems here – one being existing projects and their migration to a new platform and the other being a new project with no established base. They each have their own paths to travel and decisions to be made.

If a new project is starting up they have the ability to say “I’m only supporting PHP 5.3” they won’t catch much guff. That project can dictate what they want to do and yes, they might loose some users because shared hosts won’t upgrade, but the overall net gain as PHP 5.3 increases in market share means less support up front and possibly a better position down the road.

The other types of projects, like Zend Framework, normally will have an established maintenance plan in place. New whiz-bang features will slowly move from being in the older 1.x branch to 2.x, but that doesn’t mean development won’t completely stop on 1.x. Security patches and general bug fixes will still happen until that branch can formally put out to pasture as per the maintenance plan.

The whole version argument really hits home with enterprises. Look at all the people running Redhat that are still on 5.1.x all because their managers don’t want to leave the supported versions RHEL has established. In those cases though, they probably aren’t running bleeding edge software anyway so again, not a huge impact. The more agile enterprises will already be planning their 5.3 migration (I know I am) and won’t have a problem with software that is 5.3 only.

(There is also the fact that most well-written 5.2 code will run fine without any modifications will run in 5.3, so its more of a political and business issue than a technical one in my mind).

Veidit (@Veidit) wrote at 3/9/2010 11:22 am:

I think that Redhat Enterprise 6 will support php 5.2 in it’s packages so that’s what I am aiming for.
Waiting a few years for 5.3 is OK for me.

denderello (@denderello) wrote at 3/9/2010 12:14 pm:

Great post! I must admit that although I’m totally thrilled about the new PHP 5.3 version it’s still a hard decision to switch completely to it.

But I wouldn’t only limit this to Open Source projects. Even in companies working with PHP, Frameworks, Libraries, etc. you will face this problems, too. As an example you will have customers that don’t want to upgrade their software just because it runs on a new PHP version.

Because of all this we are working on a plan atm to run multiple PHP version to make the switch as smooth as possible at the company I’m working for.

Copyright © 2023 by Brandon Savage. All rights reserved.