PHP Versions Stats - 2021.1 Edition
See 2014, 2015, 2016.1, 2016.2, 2017.1, 2017.2, 2018.1, 2018.2, 2019.1, 2019.2, 2020.1 and 2020.2 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 packagist.org logs of the last month 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. CI environments are excluded on a best-effort basis.
PHP Usage Statistics
May 2021 (+/- diff from November 2020)
| All versions | Grouped | ||||
| PHP 7.4.16 | 13.26% | PHP 7.4 | 45.92% (+3.31) | ||
| PHP 7.3.27 | 8.46% | PHP 7.3 | 21.30% (-5.75) | ||
| PHP 7.4.9 | 6.38% | PHP 7.2 | 12.89% (-2.39) | ||
| PHP 8.0.3 | 6.31% | PHP 8.0 | 9.44% (+9.17) | ||
| PHP 7.2.34 | 5.46% | PHP 7.1 | 5.21% (-2.24) | ||
| PHP 7.4.15 | 4.89% | PHP 7.0 | 2.07% (-0.63) |
A few observations: 7.4 keeps going up despite being already very high, while PHP 8 is doing okish but sees only about half the adoption rate of the previous 7.x releases. Upgrading to it is definitely harder than upgrading to a minor release in my experience mostly due to some dependencies lagging in support for PHP 8, but it is well worth it feature wise so I would encourage people to try and push forward!
You can easily do a baseline test of whether your dependencies support PHP 8 using Composer's platform config by running for example:
composer config platform.php 8.0.5
# Checks whether latest versions of your dependencies (according to your
# version constraints) allow PHP 8
composer update --dry-run
# Checks whether current versions of your deps allow PHP 8
composer update nothing --dry-run
If this passes, you can try to actually do an update without --dry-run and run your test suite. If you get solver errors then you may need to look whether a new version exists for these dependencies, or send them a PR / open an issue about PHP 8 support.
Don't forget to revert composer.json changes to the platform config once you're done.
Here is the aggregate chart covering all my blog posts and the last seven years.
PHP Requirements in Packages
The second dataset is which versions are required by the PHP packages present on Packagist.org. I only check the require statement in their current default branch to see what the latest requirement is, and the dataset only includes packages that had commits in the last year to exclude all EOL'd projects as they don't update their requirements.
PHP Requirements - Recent Default Branches - May 2021 (+/- diff from November 2020)
| 5.2 | 0.54% (-0.06) | |
| 5.3 | 6.4% (-1) | |
| 5.4 | 6.68% (-0.99) | |
| 5.5 | 6.19% (-0.39) | |
| 5.6 | 9.34% (-1.2) | |
| 7.0 | 13.75% (-1.44) | |
| 7.1 | 18.43% (-1.95) | |
| 7.2 | 16.95% (-0.72) | |
| 7.3 | 9.67% (+2.59) | |
| 7.4 | 9.88% (+3.18) | |
| 8.0 | 2.15% (+1.96) | |
| 8.1 | 0% (0) |
Like last time 7.3/7.4 keep gaining the most, with PHP 8 also having a decent start. The most required PHP version is however still 7.1. According to the charts above I would say 7.3 is still a good target for any library looking to support most users, but 7.4 brings you nice features and is almost at 50% adoption so it's a valid option for new code. PHP 8 is still too low IMO to be reasonably required, and probably will remain so until Ubuntu 22.04's release a year from now.
A PHP 7.2+ requirement covers ~90% of the user base right now so requiring anything less than that really isn't necessary anymore, and Composer 2.2 coming out later this year will most likely require that. By the way if you are not using Composer 2 you should really consider upgrading!