Pick PHP Requirements for Packages Responsibly

Posted: 2013-03-23
Category: PHP

I recently tweeted something which seems to have confused a lot of people:

Now, don't go running off to PETA, I'm clearing kidding about the pets, but people seemed confused by the main gist of this point: If you're going to release a package (a Composer package for example) as PHP 5.4, then make sure it is worth it.

When I say "make sure it is worth it" I mean, don't just switch your arrays from array() to [] just because it looks cool. That was the extent of my original tweet, because I've seen a few packages doing that and it annoyed me immensely. This conversation became confused quickly with people assuming that everyone on Composer is PHP 5.4 because only smart cool kids use Composer (which is weird, elitist, ignores those that use composer locally but deploy to PHP 5.3 servers and according to stats from Jordi isn't true anyway), other people started wanging on about how WordPress should move to PHP 5.3 which would make companies upgrade somehow (but that ignores the fact that PHP 5.4 packages would still be out of reach) and there were about 30 other conversations going on, all spawned out of the tweet which was making one very specific point...

Suffice it to say, if you require a user to upgrade their version of PHP simply so you can use some syntactical sugar inside a package that nobody else is even going to be looking at, then you're an idiot. Beyond that, you're actually hurting the community.

If every time a developer wants to use a package they're forced to build their own because the developer of the original stupidly decided to use PHP 5.4 when only 3.1% of the internet is using that version, then we're doubling up on efforts to build useful, reusable components that we can all share.

PHP 5.4 is more than just []

There are lots of brilliant new features in PHP 5.4 that could make a developer wish to pick PHP 5.4 over PHP 5.3 for a package they build.

Just look at the "New Features" change-log:

  • Support for traits has been added.
  • Function array dereferencing has been added, e.g. foo()[0* ].
  • Closures now support $this.
  • Class member access on instantiation has been added, e.g.* (new Foo)->bar().
  • Class::{expr}() syntax is now supported.
  • Binary number format has been added, e.g. 0b001001101.
  • The session extension can now track the upload progress of files.

Most of this is traits and dereferencing, which a lot of developers love. If you plan on making heavy use of features like this, such projects like AuraPHP then great, that's a wonderful decision. We need people building components at the bleeding edge, and we need people building PHP 5.4 specific code that really shows people how to do it, but does the next package you release need to be PHP 5.4?

If you're just using traits, then make sure those traits are optional. If you're dereferencing then… well do you need to? It's an extra line of code to avoid it, and instead of making your package compatible with only 3.1% of PHP-based websites you could make it work with over 50.4%. That is the entire point of sharing code right, to actually be able to share it with people?

"But I use PHP 5.4 for all my projects"

Yes, you do, but think about other people for a minute. At Kapture we use PHP 5.4 on any PHP-based application, and I already have a PHP 5.5 branch of the API ready to go and passing tests so that as soon as PHP 5.5.0 comes out I'll be upgrading. I can do what I like, because I control the servers, but what about other people?

And not even other people, other projects?

PyroCMS for example, a few months back decided to up the requirements for the next version from PHP 5.2 to PHP 5.3. This might be seen as slow moving, but lets remember that WordPress won't be upping the requirements until 2014 sometime.

It's not just Pyro, another example would be Drupal 8 (based on Symfony2) who are in the same boat, as are plenty of other "distributed" projects.

If the amount of work it takes to keep your packages PHP 5.3 is minimal (long array syntax, keeping traits optional, and not using dereferencing) is that trivial, and it means that projects can use your packages, then surely it's worth it? This avoids PHP 5.4 people and PHP 5.3 people all building the same shit, just because one group wants to use the new hotness, even though it doesn't really add all that much.

Again, it's about sharing it with the lowest common denominator which is the same logic that is being used by that vast majority of popular Composer packages or component-based frameworks which distribute over Composer:

  • Assetic
  • AWS SDK 2
  • Behat
  • Buzz
  • Doctrine
  • Guzzle
  • Laravel 4
  • Monolog
  • Imagine
  • PPI
  • Password Compatibility
  • Pimple
  • Swiftmailer
  • Symfony2
  • Twig
  • ZF2

All PHP 5.3, because PHP 5.4 usage is not high enough yet.

So why not PHP 5.2

If we're going for the lowest common denominator, why not go for PHP 5.2?

PHP 5.2 and PHP 5.3 are worlds apart, whereas PHP 5.4 (syntactically) is just adding some sugar. Sure under the hood there are loads of speed improvements in PHP 5.4 and it's an excellent version, but the architectural differences between 5.3 and 5.4 are trivial (or non-existent) compared to 5.2 and 5.3.

PHP 5.2 doesn't have namespaces, closures, or late static binding. PHP 5.2 makes PSR-0 compatibility impossible, and that alone is a massive reason to ditch it for packages. Using PHP 5.2 blows chunks and it needs to be burned with fire, but PHP 5.4 doesn't make enough of a difference to a package to really justify using it at this time.

"But we have to push things forward"

Upping requirements of everything everywhere does not increase adoption of new PHP version support with hosting companies. Most hosting companies pay no attention to these things, and even when you beg and plead for them to upgrade they do it at their own damn rate anyway. Some more alert companies like Crucial Webhosting have been rocking PHP 5.5 since the first alpha1, for people to test their code, but this is not because of people releasing PHP 5.5 code on packagist, this is due to PHP getting more consistent and regular with their releases and because they want to carve a name for themselves as being different from the average hosting company.

The whole idea that hosting companies care about what version we use for our components is just not realistic. When you say "well if I increase my packages people will have to upgrade to PHP 5.4 quicker." you're only kidding yourself. In reality those people just won't bother looking at your package, especially if there is another one (all be it worse) next to yours.


Running PHP 5.4 on your servers is going to make your code quicker and I can't recommend it enough, but using PHP 5.4 specific syntax doesn't change a thing. It makes some code a little cleaner, which most people wont ever see because its buried away in a package they wont bother looking at, and comes at the cost of drastically reducing adoption of your packages. In your applications you should use all the syntactical goodness that PHP 5.4 provides, just keep it out of your packages unless you need to. And if you think you need to, do you really need to?

As long as you understand that the usage will be much less and are ok with that (like Aura) then that's fine, but don't release some generic Geocode or OAuth 2 package as PHP 5.4 just because you prefer [] over array(). I don't want to have to hurt any pets.


Jonathan Barronville


Hey, Phil.

Thanks for writing this up. Although many people may just consider your post a normal "Phil Sturgeon rant", I really couldn't agree with you more. I've actually seen a few open source projects where the authors will declare ending 5.3 support just because they "want" (not necessarily "need") to use traits or, as you've mentioned, to use the short & standard array syntax, or for the simple fact that you can always use the short open tag syntax, or even just for proper binary representation. That constantly pisses me off because those are honestly not solid enough reasons to make such decisions. They are certainly awesome and a big step ahead for PHP, but not good enough reasons to make such decisions.

  • Jonathan.
Hari K T


okey, I agree you and your thoughts are true.

Just for [] switch is not a valid reason. But that can be another tab vs spaces :-) .



Correct me if i'm wrong "Please note that the PHP 5.3 series will enter an end of life cycle and receive only critical fixes as of March 2013" http://php.net/archive/2012.php#id2012-12-20-1 looks at calendar

5.3 has some issues too https://github.com/ircmaxell/password_compat/issues/10, and can be a real pain point http://zend-framework-community.634137.n4.nabble.com/Minimum-PHP-Version-to-5-3-5-td4658910.html.

Choose your php version requirement "as if the person who ends up maintaining your code is a violent psychopath who knows where you live." http://www.codinghorror.com/blog/2008/06/coding-for-violent-psychopaths.html

I've said it before, only when cool stuff use latest versions will new versions be embraced. v4 anyone, v5.2 anyone.



Gerard: PHP 5.3 entering end of life sadly does not have any actual bearing on it's usage. This has always been the case, even though it's clearly not ideal.


PHP 5.2 is still going, but is slipping down the charts fast. This is great news, but as you can see PHP 5.3 is the largest user base, and PHP 5.4 has barely anyone actually using it percentage wise.

I know about that password_compat issue. I remember having a conversation about it while sat in ircmaxell's car. That's a specific bug in a specific version of PHP 5.3.7 which relates to bcrypt, we can hardly use that as a reason against using PHP 5.4 specific syntax in your generic packages.

"Choose your php version requirement "as if the person who ends up maintaining your code is a violent psychopath"

Yep, it's a great blog. I'd much rather be using well used and maintained packages with thousands of installs, than have to use my own personal fork which makes it backwards compatible with PHP 5.3 because PyroCMS needed to use it. That would make people angry, right? If it's 5.3 I can use it out of the box.

"I've said it before, only when cool stuff use latest versions will new versions be embraced. v4 anyone, v5.2 anyone."

Oh well if PHP 5.3 is not cool, then let's just ignore the usage numbers and release all of our code as PHP 5.5.0-beta1?

I think you're totally missing my point on the separation between:

A.) YOUR code, applications, API, whatever.

B.) Generic packages that you want to share with the internet.

We're talking about B here. If you want to share, share it with 50.4% of the internet, which can all use namespaces, closures and useful modern architectures. PHP 5.2 and 4.0 don't have those, so lets skip them and use something sensible. PHP 5.4 is not useful enough to restrict the use of packages we develop to only a tiny fraction of the community, so PHP 5.3 is (for now) the most obvious minimum requirement to target for generic released code.

George Robinson


I upgraded an application I was writing purely for function array dereferencing. It made my code much easier to read and maintain.



George: Right, you upgraded your application. Im talking about packages (reusable, sharable, PHP components). What you do behind closed doors is completely up to you.



Hari: array() v [] is not tabs v spaces. TvS (thats what we're calling it now) is a completely A or B choice, where as array() v [] is based on a specific version of software that can potentially limit the usage of your code drastically. Picking TvS does not stop your code from running on another server.

Daksh Mehta


Great though. Well, If everyone gotta do on Composer, Don't you think we will lose backward compatibility ( with respect to version of PHP )?

Andy's Tree Pruning


If some one needs to be updated with newest technologies then he must be pay a visit this site and be up to date everyday.

Posting comments after one month has been disabled.