5.3??? 5.3 has been EOL for 3.5 years now. I do not envy the person that has to maintain backports for so many years. In fact, I'm not even sure all the backports would always work properly...

I was referring to new code and code packages that are available out there.

It sounds like you are talking about providing hosting for older versions of PHP code. Which I of course understand is a necessary thing. You can't force people to upgrade their codebase. They'll just find another host.

Yeah, it's... ugh. I've got to deal with a mission-critical PHP 5.3 app. It goes down, and a subsidiary of around 700 people can't do their sales, control production flow, or create their invoices.

But they'll finally listen to engineering... any year now...

What's the friction for upgrading from 5.3 to at least 5.5?

Please see point #2 if you're still confident that 5.3 to 5.5 should give a host like mine no trouble:

"PHP 5.3.3 (with backported security and bug patches) remains the default in CentOS 6.9, which is supported until 2020. More recent versions are not available via their repositories. Hosts would have to upgrade PHP outside of the CentOS packages and assume the maintenance burden from then on."

https://news.ycombinator.com/item?id=16161455

The point isn't that you can't or shouldn't do it, but that it is much more trouble than you might think for many people. There are implications that apply to others that you might not see or care about for your particular situation.

If your distro's package maintainer is asleep at the wheel then you'll have to take matters into your own hand and source install.

The Node team has done a great job here, they have a number of ways of doing managed source installs that avoid a lot of the ugly hassles you can usually hit. Ruby has rvm which also handles this quite well. This helps work around any friction you might get at the distribution level.

If PHP is being held back by distribution maintainers then that's a problem that the PHP community should fix. 5.3 came out in 2009, it's ancient.

register_global

If you're using that you're going to hard-fail even the most cursory of security audits.

extract($_REQUEST);

Look, one-line register_globals polyfill.

This kind of breezy dismissal is really frustrating. Developers and admins in the field are dealing with this situation for the reasons I gave above, and not out of simple ignorance.