United PHP 7.1 Adoption 6 Months Later
How is adoption going in open-source and why it should continue from bleeding-edge projects?
"United we stand, divided we fall."
How is GoPHP71.org Doing?
In release post I've explained why right to PHP 7.1 and not PHP 7.0, how important is united community in this and how this can bring positive energy to open-source and as well host providers upgrades.
From 2 projects in June 2015:
Now there are 11 projects, including big 3 - Symfony, Doctrine and Laravel.
Is your project missing? Go and it!
Prove beats Promise - Packagist Stats
Great Job, PHP Community!
It makes me very happy, that people from PHP community are able to synchronize despite their different opinions on things.
Special Thanks to Doctrine Project
I really loved this Doctrine bump PHP 7.1 announcement. I completely agree with "Why dropping PHP support in a minor version is not a BC break" part. If you think PHP version bump is BC break, you should read it.
But I want to go PHP 7.0
Still not convinced about reasons? Check this issue on
@dmonllao poses question or rather idea there: I want to take is slowly
Let me explain how that could influence PHP ecosystem and slow down productivity of many projects:
- Imagine that in 6 months all of those 11 projects on gophp71.org will require PHP 7.1 in their LTS versions.
- Moodle (could be any other package, it's just example) decides to go with PHP 7.0.
- If you work with PHP, there is quite big chance you'll be using at least one of those 11 packages.
- Let's say you want to use newest features + LTS, so you bump your local nad server to PHP 7.1.
All good for now, but then:
- You need to use Moodle in your project. Its code contains only PHP 7.0 features.
- Your code naturally extends or implements 3rd party classes. You can use PHP 7.1 on most of them - e.g.
voidand nullable typehints of interfaces.
- But then your need to extends Moodle's code and you have to be careful and use only PHP 7.0 features. Features like
nullablewould break it.
Result? Double Measures & Dichotomic Coding
- You have to have 2 different coding standards - one for PHP 7.0 and one for PHP 7.1 with various paths to scan.
- If you use static analysis like PHPStan, you have to have 2 configs again to validate code properly.
- 2 testing approaches etc.
And that's only 1 package with different PHP version. Imagine there would another package that requires PHP 7.2... or if you combine PHP 7.0 and PHP 7.1 interface in single class.
But I don't want to Drop Support for PHP 7.0
I've borrowed this amazing picture from Jordi.
You can keep support for older PHP version even if you bump minimal requirement to PHP 7.1, just won't add new features to them.
Spread the Word
At the moment only 4 projects on are tagged and it will take some timer before this becomes mainstream. Yet, we can see obvious trend moving to PHP 7.1 as minimal requirement. Thanks to community and people that are bold enough to ask the question or even sending a PR.
If you see some next project bumping to PHP 7.0, think about possible consequences of that decision.