Now that the naming debacle of PHP 6 vs PHP 7 is behind us, the timeline for PHP 7 has been announced.
With key decisions about both the version number and the engine for PHP 7 behind us, it’s time to define an agreed-upon timeline so that all contributors can align around it. The purpose of this RFC is to define a one year timeline for the delivery of PHP 7.0, with a projected release date of November 2015.
So good news: PHP 7 is aiming for Q4 2015 for release. Take into account the usual delays software projects encounter, and we should be seeing PHP 7 in production Q1 or Q2 2016. Quite some time left, still. But the RFC contains a warning for BC breaks that may hold back some of the development in PHP 7?
While we should definitely take the opportunity to implement compatibility-breaking changes in 7.0, we also shouldn’t turn it into a compatibility-breaking festival, as the more we break, the more likely it is users would delay upgrades, stay with old, insecure versions, …
Granted, the “but”-statement is very valid. Too many changes, and you risk losing the game to competitors like NodeJS (or it’s recent fork, io.js), Ruby, …
I still see PHP 5.2 running in production, because the code-changes required to upgrade to PHP 5.3 were just too much. I understand the risks involved for PHP 7 as well, but this isn’t a minor version bump. People expect BC breaks for major version changes. Nobody likes them, but they’re expected. And those serious about PHP development will take that into account in their internal development roadmaps.
This is the unique opportunity in the PHP community to “fix” some of the wrongs in the language. The inconsistent function calls that other languages often use to mock us PHP developers, Unicode support, a JIT compiler that rivals HHVM, true async PHP, … I truly hope they all meet the PHP 7 deadline.
If there’s ever a time to introduce BC breaking, it’s now. All those minor versions (5.2, 5.3, 5.4, …) have dragged along 10 years of PHP heritage (the first PHP5 release was in 2004, that’s 10 years ago) and they’ve finally reached a point where there is an opportunity to set the record straight. To fix the inconsistencies.
If the PHP community doesn’t take this opportunity to introduce BC breaks with the vision to support the language for the next decade, I fear we’ll be seeing a decline in the PHP popularity, in favor of other, newer languages.
PHP may be old but it’s survived all these years. Here’s to another decade of PHP releases. May they be as successful as all the previous ones.