The PHP world is mired in legacy codebases. I have seen many code bases that are on very old, unsupported PHP versions. Although PHP strives to maintain backwards compatibility, it doesn't always work. And many of the backwards incompatible changes are only apparent at runtime and are incredibly difficult discover due to the dynamism of the language and the abuses that are present in most legacy PHP code.
"PHP strives to maintain backwards compatibility", I'll have to say I've seen enough evidence to the contrary. Even basic object-oriented metaprogramming have been radically changed in minor point/patch releases. Stuff like "get_class_vars()" changing from returning private vars, to not returning private vars, etc. (edit: between PHP v5.2.6 and v5.2.7 if I remember correctly)
Although true, I would say that's kind of an "abuse". I find many PHP functions have changed over versions to give more predictable output and validate expected input more stringently. If backwards compatibility wasn't a concern, they would attempt to standardize the lib in obvious incompatible ways.
Well, backwards compability is kind of a binary thing, isn't it. Either you're aiming for backwards compability and you can be sure your legacy code will keep running, or you don't. In fact it would be more helpful to throw fatal errors because a method signature changed, than start returning different and unexpected values which can break data integrity in subtle ways.
Today's PHP doesn't really want to support legacy code. A customer's hosting provider forces an upgrade to PHP 5.4 in April. They tested a CMS and it is broken. Just because the CMS used split() instead of explode(). Deprecated function.
especially nasty is magic_quotes , switch your old website to a new webhost (or have your existing one upgrade their PHP installation) and you get instant SQLi vulnerabilities.
