Hacker News Reader

Comment by thetrumanshow | Hacker News Reader

I'd like to get a sense of how often the PHP community tends to upgrade languages and frameworks for legacy products. Always/Never? Anyone care to provide some anecdote?

For example, I have two Rails apps that are running on Rails 2.2.x, so yeah, they're way behind, and I feel some sense of urgency to upgrade them soon... but I believe I am an outlier in the Ruby/Rails community in the sense that I am not upgrading all the time.

View on HN

I usually upgrade as soon as it's stable. There has never been a downside as far as I can remember, because the old stuff usually just keeps on working. Whether that's been good for the language itself is debatable, but I imagine it sure helped adoption since they almost never break anything when they push out a new version.

Personally, I always wait at least one year before upgrading PHP. There are always segfault or security issues or odd problems in a 5.x.0 release. It's around 5.x.4 that it becomes just stable enough to use.

About a month or two before I decide to upgrade I run the newer version locally while I'm developing (but being sure to not use any newer features). This usually weeds out any major incompatibilities and fix new warnings.

That said, I'm running 5.3 in production and have no real plans to upgrade to 5.4 anytime soon.

>That said, I'm running 5.3 in production and have no real plans to upgrade to 5.4 anytime soon.

May I ask: why not?

There is no real compelling reason for me to upgrade. The short array syntax is nice but it's not worth spending a day or more interrupting everyone's dev environments and building packages and introducing (potential) instability into something that I live off of.

You build the packages yourself? Is there a special reason why you need to do this?

Consistency. I use the system packages right now and Ubuntu does some tricks with the config that I'm used to.

Can you be more specific?

If you want to see the patches go into the Debian/Ubuntu packages, run apt-get source php5 and look at the php5-$version/debian/patches directory. The build process uses a quilt wrapper (dh_quilt_patch) to apply them in the correct order. There are patches for building (in general or for a specific architecture), segmentation faults, security issues, manual pages and very few configuration changes (mostly just FHS compliance).

That's pretty much exactly what I try to do. I grab the sources for the package and upgrade the underlying php version. I usually have to grab the PHP sources from a newer version of Ubuntu and modify it until it builds.

I've BTDT and it's tedious at times. Try this PPA: https://launchpad.net/~ondrej/+archive/php5

Fedora users have it easy, the packages there are mere days behind: https://admin.fedoraproject.org/updates/php

With a bit of experimenting you can easily do a network install of a headless Fedora/SL/CentOS in KVM using virt-install and a kickstart file. Use filesystem passthrough to access your source files, run php-fpm and configure its address as a backend in your web server. Keep SELinux enabled, but adjust it to your needs using setsebool if necessary.

That first link looks like exactly what I need, thank you!

I've tried Fedora in the past. I found it unstable and broken and I don't like RPM very much. It's undoubtedly improved since I last tried it (c. 2005-2006) but I don't miss RPM at all.

RPM is fine, I'm more worried about Journald, Systemd and the like. The programs they replace are much more elegant and simple by design.

CPU usage and memory consumption are cut by a third at worst and cut in half at best, personally I find that to be pretty compelling. It's a minor performance improvement but it's basically free.

Also on 5.3. I'm encoding my php files with zend guard, and they don't support php 5.4 yet, which is ironic given that it's zend.

Right now I'd say the only major "jump" that exists is the one between PHP 4 (released +10 years ago) and PHP 5. Other than that, apps are largely backwards compatible between 5.x versions, except for a few minor changes that no dev really stresses about.

The thing about PHP is that since it's massively used around the net, rather than forcing devs to catch up with the language, PHP devs themselves try as much as possible not to break backwards compability. Which in many ways is a pity, but that seems to be the direction of the language at the moment.

Actually, I would call 5.3 as a fairly major jump - namespaces, closures (Lambda/anonymous functions), late static binding, const's allowed outside of classes. There are several popular PHP frameworks that require v. 5.3+. Some people even go so far as to call the 5.3.x branch “php 6 without Unicode”.

Yes but most, if not all, PHP 5.2 code runs on PHP 5.3 without modification.

As recently as this week, I came across a production server that was running PHP 4.4.x. A lot of popular apps continue to be written with PHP 4 compatibility in mind, which really hinders their ability to clean up bad code. Security updates for PHP 4 have been non-existent for several years already, so I try to stay away from these machines. Well, actually, I think some Linux distros (Red Hat?) still offer security updates for PHP 4, or did so until quite recently, but I can't remember the exact versions/dates.

A large number of web hosts still run PHP 5.2.x, while many have migrated to PHP 5.3. My last PHP 5.2-based client moved to a PHP 5.3-enabled web host a few weeks ago, so I'm finally free to use namespaces and closures.

Debian Stable and Ubuntu LTS are currently on PHP 5.3.x, which I suspect is partially responsible for the lack of PHP 5.4 adoption.

As for myself, I'm planning to rebuild my Ubuntu LTS dev box when Mint 15 comes out, so that's when I'll be upgrading to PHP 5.4. No need to hurry when none of my clients can use it anyway.

Dreamhost, as a shared hosting provider, has within the last month rolled out the option of PHP 5.4 on all their servers.

I wish all hosting providers would make newer versions available, then maybe open source projects would move with the times, and start bringing everyone up to date.

PHP tends to remain backwards compatible for a few major versions. Right now PHP has stable recent releases of 5.4 and 5.3. There is a bunch of older (5.2 and lower) PHP installs running around the web as well, since many cheap shared hosts aren't quick to update their installs.

We keep up to date on the build version, but the first decimal version (4 in 5.4, is that considered the minor version?) usually involve at least some backward-incompatible changes, so there is usually a need to test the codebase against new minor versions.

Reply on news.ycombinator.com