Something Breun posted in another topic prompted me to post this.

I'm expecting/hoping that 5.3 is going to be the highest version of PHP most scripts will need for some considerable period of time (some years, anyway), in the same way 5.1 was in the past, and so I'm intending to upgrade our servers to the Centos/RHEL php53 version rather than the ART version.

Does this seem reasonable or not? It wouldn't be so bad if the PHP devs didn't keep deprecating stuff in point releases instead of in major releases.

The ART versions are obviously superior in a number of ways, of course, and I think I'll keep at least one server using them in case anybody ever does need a PHP version on the cutting edge.

Of course it would be even better if Scott felt like octupling his workload and creating an LTS PHP version. Now that really would be ideal.

If you don't like upgrading to every PHP release right after it is released, I think it makes sense to go with the EL5 php53* packages instead of the ones in Atomic.

The PHP 5.4 beta's are already out with safe_mode, register_globals, register_long_arrays, magic_quotes_gpc, magic_quotes_runtime and magic_quotes_sybase ini options removed, amongst others.

One downside of going with the EL5 php53* packages that I found is that there are no php53* versions of the packages in EPEL. This means that there is no php53-eaccelerator package for instance. See threads like http://forums.famillecollet.com/viewtopic.php?id=503 for more info on why. It seems Red Hat didn't completely think their php53* release through. Google for 'php53 epel' and you'll find more of these stories.

Too bad it seems there is no real answer to a full featured long term support PHP 5.3 stack on EL5.

Thanks Breun.

It wouldn't affect us now, but I'm going to look into this as it might in the future.

Everything Ive read for the 5.3.x branch is that its API is fixed, other than bug and security fixes all the new features/deprecations are going into the 5.4 branch.

I guess you'll be upgrading the packages in Atomic to 5.4 when it's out, right? That will be a major upgrade for shared hosting providers because of all the functionality they'll be removing. Upgrading from 5.2 to 5.3 was already pretty painful for some our clients, but it sounds like 5.3 to 5.4 will be even more painful.

That's why I was looking into a long term supported EL5 PHP 5.3 stack. I thought I had found it in the EL5 php53* packages, but that only seems to be an option when your needs are satisfied by the packages in the EL5 repository, since it doesn't look like EPEL5 will be providing their extensions for php53*.

It seems the IUS repository is currently maintaining both PHP 5.2. and PHP 5.3 for EL5, but I don't expect them to provide long term support either.

whatever comes after 5.3.x will go through the same process that we did for 5.2 to 5.3. Lots of testing builds, and a open forum to discuss the transition. If you recall it was over a year after 5.3.x was initiated that it finally went into the stable channel. And even once we had a majority, then it was only after php.net officially dropped support for 5.2 that it went live.

The is a very interesting repo that I wasn't aware of.

It is a great idea: Here's a huge hosting company that needs long term support for certain packages - php being a great example - and wants to keep them up to date, so they come up with this nifty project which gives back to the community and gets loads of people to test them beforehand. Perfect.

But as you say, they look to be moving to PHP 5.4 before long.

There must be 1000s of hosting companies in the same situation as we are. Why isn't there a solution?

There's no point in me trying to do it. In theory it might be easy to merge a bugfix (assuming one is posted) into the source for an older package, but in practice it is undoubtedly very hard.

Well before you get yourself into a panic here, even if php.net drops support for 5.3 expect this repo to do exactly what happened when they dropped support for 5.2. Fixes will be backported just like last time, and we'll have an open public discussion about transitioning the repo to a newer build when that happens. I'd continue doing that indefinitely provided there was a large enough userbase.

BTW php 5.2.x is still maintained for ASL. Assuming we transition ASL to a 5.3 base php it would follow the same process.

I agree with Remi in that the php53 packages are a poor half-measure. A lot of secondary packages are not built for it and it will be more difficult to move forward in the future.

I think RedHat will have to rethink some of the premises of EL in general. 7 Years is a long time to lock into a particular package and, in reality, PHP 5.1 is long past EOL. It's also important to note that PHP 5 is an increasingly mature application. The pain of 5.3 to 5.4 should be very minor now (even MySQL upgrades are now pretty painless) and I can't see 5.4 breaking anything 5.3 compatible.

Red Hat is providing the same packages that they are providing for PHP 5.1. Red Hat does not control what third party repositories do with this. Although they might have set this up in a way that would have made it easier for third party repositories, I'm not sure.



You're not forced to stick with the same OS version for 7 years. The point is exactly that you can stick with the same stack for 7 years if you want to. That's the value that Red Hat provides. They make sure that the software is maintained, even when the original maintainers have declared it EOL. That's actually pretty awesome.



That's not the idea I got from reading through the 5.4 beta changelogs. They'll be removing functions and settings (safe_mode, magic quotes, etc.), so it definitely won't be a drop-in upgrade for everyone.

I certainly don't have a problem with maintaining it into the future. PHP is the longest running package in the repo (since jan 2003 baby!), pre-dating even yum support.

Thanks Scott. This is interesting.

Is there any possibility of making it slightly more formal? I'm thinking in terms of a date that you'd be willing to say was the minimum latest date you will attempt (not guarantee) to continue to support 5.3? Ideally support would continue past that date, but if you didn't want to for some reason then us consumers of that "free" repo would have no grounds for disappointment after that point.

I hesitate to suggest it in case there's a licensing or moral issue that I've not thought through, but I suppose you could move it into the ASL repo after that date, and maybe continue to support it for a bit longer? It could add value to the package without too much additional effort? I suppose you'd have to have an even more formal EOL policy on it in that case, however, which might be a pain in the neck for you.

Sorry if any of these ideas or suggestions are stupid. I'm just thinking outloud.

Sure, just like any major change we'll discuss the impact and reach a consensus on the right way to implement it. Like maybe an [atomic-legacy] channel or something.