Jordi Boggiano

Jordi Boggiano Co-Founder of Private Packagist – Dev at TeamupComposer lead – Wandering Belgian – Speaker

Blog RSS Feed Twitter @seldaek


PHP Versions Stats - 2016.2 Edition

It's stats o'clock! See 2014, 2015 and 2016.1 for previous similar posts.

A quick note on methodology, because all these stats are imperfect as they just sample some subset of the PHP user base. I look in the logs of the last 28 days for Composer installs done by someone. Composer sends the PHP version it is running with in its User-Agent header, so I can use that to see which PHP versions people are using Composer with.

PHP usage statistics

I have two datasets, from May 2016 and today, which shows the progression of various versions.

May 2016

All versions Grouped
PHP 5.5.9 11.87% PHP 5.6 39.67%
PHP 7.0.6 10.39% PHP 5.5 29.56%
PHP 5.6.20 8.41% PHP 7.0 20.24%
PHP 5.6.21 7.69% PHP 5.4 7.64%
PHP 5.6.19 4.71% PHP 5.3 2.43%

November 2016

All versions Grouped
PHP 7.0.12 8.58% PHP 5.6 37.46%
PHP 5.5.9 8.25% PHP 7.0 35.01%
PHP 7.0.11 7.62% PHP 5.5 18.93%
PHP 7.0.8 6.92% PHP 5.4 5.40%
PHP 5.6.26 6.12% PHP 5.3 1.60%
PHP 5.6.27 4.49% PHP 7.1 1.36%

A few observations: 5.3 and 5.4 at this point are gone as far as I am concerned! 5.5 still has a good presence but lost 12% in 6 months which is awesome. 5.6 basically stayed stable as I suspect people jumped from 5.5 to 7 directly probably when upgrading Ubuntu LTS. 7.0 gained 15% and is now close to being the most deployed version, 1 year after release! That should definitely encourage more libraries to require it IMO, and I hope it is good encouragement to PHP internals folks as well to see that people actually upgrade these days :) Interestingly 7.1 is almost passing 5.3 already and it isn't even released. That is probably coming from CI installs mostly but for example I already run 7.1 on my local dev environment and I hope others do too.

PHP requirements in Packages

The second dataset is which versions are required by all the PHP packages present on packagist. I only check the require statement in their current master version to see what the latest is.

PHP Requirements - Current Master - November 2016 (+/- diff from May 2016)

5.2 2.35% (-0.16)
5.3 41.25% (-4.01)
5.4 30.12% (-1.57)
5.5 16.98% (+1.5)
5.6 6.22% (+2.7)
7.0 3.08% (+1.54)

A few observations: I don't know how else to say this but PEOPLE COME ON! This is moving waaaay slower than people are migrating their servers, and it doesn't make any sense to me. I guess there are a lot of projects out there that are somewhat stale or stable and not really changing and that makes sense, but if you still maintain a library, don't hesitate to require 7 and bump the major release at this point. You will have more fun using all the cool features of the language instead of being stuck writing array().

As I wrote in the last update: I would like to encourage everyone to be a bit more aggressive in bumping PHP requirements when tagging new major releases of their libs. Don't forget that the old code does not go away, it's still there to be used by people using legacy PHP versions.

However it seems that a lot of people here do not read and just look at the pictures, so allow me to illustrate this last point.

November 18, 2016 // PHP

Post a comment

Subscribe to this RSS Feed Comments

2016-11-18 09:13:09

Bhaktaraz Bhatta

Good read!

2016-11-18 09:47:11


Interesting, only problem is that composer is being used by "modern" apps and frameworks. Legacy crap doesn't need composer and numbers will be much less optimistic.

2016-11-18 09:47:37


Thanks for the statistics, interesting to see that old PHP versions are still around and that not all users/companies have moved on to the newer versions. One of my customers is still using PHP 5.2 and won't upgrade (due to the mssql_* functions used throughout various projects) but I can't imagine to go back to one of those prehistoric versions :-)

2016-11-18 11:46:08


Talk about misleading stats! None of my old php 5 based sites run composer!

2016-11-18 18:47:12

Jeroen De Dauw

If your sites don't run Composer, then there is no need to care about them when publishing a Composer based package.

It's very true though that these stats definitely don't give you a picture of PHP usage in general. Composer is not a deployment tool, so you should not even be running it on your actual production machines.

2016-11-19 19:48:03

Rasmus Schultz

Plenty of stable, maintained packages simply do not need any newer PHP features. I've bumped a few packages to 5.5 or 5.6 more recently because they needed those features - almost nothing I've written needs a PHP 7 feature, so... I'm not going to bump version requirements for no reason, why would I do that?

2016-11-22 14:35:30


I have to agree with Rasmus on this. Surely the ecosystem will be more interoperable if packages specify a true minimum version requirement – i.e. "this package *requires* feature X, Y, Z which was introduced in PHP 5.6, and therefore *will not run* on anything less".

The whole point of composer is to foster an ecosystem where it's easy to use packages that are compatible with each other.

My concern is: artificially bumping version numbers 'just because', feels just a small step away from a dependency hell rife with incompatible packages.

I understand that it's a Good Thing to encourage people to use the latest stable version of PHP, but I don't agree with artificially bumping version requirements. It feels like a step in the wrong direction.

2016-11-23 08:06:53


@Paris: As I mentioned early in the post, this is only representative of Composer users, which tends to be more PHP devs than people installing ready-made PHP apps so it is a skewed view for sure, but not an uninteresting one. You just have to know what you are looking at and what you are looking for.

@Rasmus/Ollie: I can see that point, but for having worked on a PHP7 version of Monolog (for v2) and now a PHP7.1 project, bumping the requirement has a few benefits IMO: It is more motivating for people to work on it, rather than having to constantly think back "ah no I can not use that in this project..". It is also easier to keep track of things, if you can use any feature you can think of, as opposed to having to keep in mind which feature was introduced in 5.4, 5.5, 5.6, etc. if you keep switching between projects. It just makes the adoption of new features faster and IMO if everyone gets used to upgrading their servers it does not hurt a whole lot of people. I can see not everyone will agree with my perspective though.

Last modification : 2016-11-23 - 08:14:53

2016-11-24 12:44:27


It would be interessting if you group your results by EOL, supported releases, current relese and future releases.

2017-01-07 12:44:51

Tomáš Votruba

Again, thanks a lot for data!
This should be somehow integrated in composer itself, so everyone could easily and instantly see what are the stats.

2017-04-03 08:08:55


Thanks for these interesting stats. To put the numbers into a more global perspective, have a look at />

2017-04-03 08:10:33


Looks like your automatic URL linking does not work ;)

2017-05-19 18:34:19


While this is some great work Jordi, as well as taking the time to admit that these stats are imperfect, (kudo's to you!) I also own a company in which we design custom software. Surprisingly, there are still many companies running PHP versions as low as 4.4.X through 4.7.X. With this in mind, its extremely important to keep coding habits agile as possible during upgrades. I.E.; Many manufacturing companies that require automated test, or run data acquisition test environments that utilize various languages across the board have been glued to older versions of PHP due to software that surrounded these older versions, as well as budget constraints.

Keep up the great work and your motto! (New Releases DO NOT disappear Old Ones).