Maybe PHP6 could be a complete cleanup. And maybe the focus shouldn't be on backward compatibility but on running <6 and 6 side by side.
- Logs usage of old or (to-be) deprecated functionality
- Provides deprecated functionality so that existing code doesn't break
This way;
- The PHP API can finally be cleaned up (please, also move those old functions to a separate section in the documentation)
- Older code can still run, but enabling the 'migration/compatibility' plug-in (should be possible to enable/disable this per site, not for the whole server at once)
- Developers are informed that their code uses deprecated functionality, giving them time to migrate code.
Although this approach is comparable to the E_STRICT flag, it is going one step further, in that the deprecated functions are actually removed from the core, and must be manually enabled/added via an optional plugin.
Reorganising the documentation is an important part of this; cleaning up the old stuff will make PHP less confusing (should I use 'implode()' or 'join()'?), and will silently guide new developers away from the old stuff.
On a final note; if this approach allows hosting-providers to upgrade PHP without breaking their client's code, adoption rate of newer PHP versions will probably be faster as well!
One of the problems with Python is that they almost encouraged writing code in 2 and porting it to 3. Also: Python 3 is almost a complete different language.
It would be the same when PHP6 would use a + as string concatenation. Such changes would turn it into a complete different language.
Somebody who has used both will notice that Python 3 is syntactically and semantically almost identical to Python 2 in most respects. The main differences are in terms of removing redundancy, removing outdated features and functionality, increasing consistency, vastly improved Unicode support, and standard library improvements.
A developer with Python 2 experience should be able to pick up Python 3 in about 30 minutes, at the most. That's not what we'd expect were Python 3 "almost a complete different language".
The big thing with PHPv5 was not just having to migrate code, but even at the time v4 was no longer supported and v5 had been out for years in benchmarks v4 was still 20-30% faster then v5.
v5 to v6 could be a similarly smaller scale migration. The number of backwards incompatible changes in 4 to 5 wasn't long:
http://www.php.net/manual/en/migration5.incompatible.php
Slashdot thread from the time with some details on the resistance:
http://beta.slashdot.org/story/87591
Migrating from v3 to v4 was also a backwards incompatible leap:
http://www.physnet.uni-hamburg.de/physnet/php/migration4.htm...
So the PHP project has pulled it off twice already, perhaps they don't get enough credit for that.
Individuals and organizations with extensive Python 2.x software systems have been able to continue using those with no problems.
Development has been able to continue on Python 3.x without needing to worry about backward compatibility with Python 2.x. It is a cleaner language, in many ways.
Over time, we have indeed seen libraries, frameworks and users migrate from 2.x to 3.x as it benefits them. It's not something that's forced on them, causing disruption and anger.
And so we've gradually seen Python 3.x starting to become more and more adopted, while Python 2.x slowly fades away. It's a non-disruptive, steady transition.
If you want to talk about a real fiasco, Perl 6 is a much better example. Having no truly usable implementation after nearly 15 years, and thus basically no adoption, does qualify as a disaster in every sense.
P.S. But from close-up, it's the think-tank and test-bed of potential Perl 5 upgrades. Even if Perl 6 never ships, it's contributed tons of shipping code for Perl 5. Yes, it's hard to understand that from a distance, and it's not a PR dream, but oh well.
I question this claim. Perhaps it's true of some syntactic features (`say` comes to mind as do some proposals for function signatures), but the semantics rarely translate over well (consider smartmatch). If you squint and tilt your head you can claim that Moose is an example of a feature designed in one language and implemented in another, but Moose is more an exercise in language/feature syncretism than it is porting something complete in implementation or design to Perl 5.
If we could get on the same page what the new naming conventions and parameter orders are supposed to be, we could start to use a shim file on 5.x to prepare for 6.x.