PHP 5.5 alpha

[Highland]

Less a request and more a heads up. PHP 5.5 is now in alpha (5.4a1 came out 6/28/2011)
Not sure where 5.4 is for ASL (no major repos have it live but remi has it in testing)

http://www.php.net/archive/2012.php#id2012-11-15-1

[mikeshinn]

Not sure where 5.4 is for ASL (no major repos have it live but remi has it in testing)

ASL uses PHP 5.4, and has for some time:

# rpm -qa | grep asl-php

asl-php-cli-5.4.9-9.el6.art.x86_64
asl-php-gd-5.4.9-9.el6.art.x86_64
asl-php-pdo-5.4.9-9.el6.art.x86_64
asl-php-5.4.9-9.el6.art.x86_64
asl-php-process-5.4.9-9.el6.art.x86_64
asl-php-common-5.4.9-9.el6.art.x86_64
asl-php-mysql-5.4.9-9.el6.art.x86_64

[scott]

I think the apps have gotten a lot closer to being compatible with 5.4 now.

[Highland]

5.3 is slated for EOL in March 2013
http://php.net/archive/2012.php#id2012-12-20-1

I also noted remi has now mainstreamed their 5.4 stuff (live channel)

[scott]

Im ready to go with 5.4 here at any time, we've had it in ASL's tortixd daemon since the summer.

Has anyone had any conflicts with 5.4 yet?

[faris]

EDIT: I'm totally revising my post.

So what are the really important changes?
http://php.net/manual/en/migration54.incompatible.php

register_globals being removed is a major problem. A lot of code relies on this. Yes, BAD BAD BAD. But it does.

safe_mode being removed Hmm...maybe a thread could be started specifically addressing this? With safe_mode gone, is running php via mod_php out of the window and everything has to be via fastcgi? (or mod_ruid2 or whatever)?

Also could we possibly have a get out of jail free card please? Specifically, a method, that works with Plesk without any issues, to go back to 5.3 if an upgrade to 5.4 proves to be a major problem?

[scott]

All excellent questions, we can certainly hold off on 5.4 until the official EOL. We can probably hang on for a while after that unless there is some major flaw pops up.

[Imaging]

Based on how I read their statement, it appears that March, 2013 will start the end of life cycle process so critical fixes should go well beyond March:

__

Please note that the PHP 5.3 series will enter an end of life cycle and receive only critical fixes as of March 2013.

__

From a security perspective, presumably PHP 5.3.x should be okay beyond March so not quite as pressing to have 5.4.x be the standard if support were completely gone as of March, no?

[faris]

And just to emphasise -- I'm not in the least bit looking forward to *having* to go to 5.4.

I want 5.3 as long as possible. I dare say others do too.

I'm not aware of any scripts at all that require 5.4 nor any mainstream ones that are even planning to require 5.4 anytime soon.

[breun]

I want 5.3 as long as possible.

You could consider using EL5's php53* or EL6's php* RPM packages. EL5 is supported until March 2017, but sadly a lot of extensions are not packaged for php53*. EL6 is supported until November 2020.

[faris]

Well, we went with the Atomic 5.3 because I prefer them and in another post Scott reassured us that he'd keep his 5.3 going for as long as possible/practical (as long as there was demand for it of course) with backports etc.

I'd have stuck to the EL6 versions otherwise.

Picking a date out of the air, I'm thinking 12 to 24 months, maybe even 3 years, is the time to upgrade to a new version that has significant incompatibilities with older scripts. But that upgrade, whenever it happens, won't be to 5.4. I simply don't see anything in it that offers anything new that's actually useful to mainstream users compared to 5.3.

I've not looked at the timeframes, but maybe by then we'll be looking at 5.6 or 5.8 (6.x?). ext/mysql will definitely be deprecated in 5.6 - and possibly removed completely. Now that will cause havoc when it is removed. I can think of several several customers I know of with scripts that rely on this which are no longer actively maintained. It will require us to start warning customers 6 to 12 months in advance.

[breun]

Well, we went with the Atomic 5.3 because I prefer them and in another post Scott reassured us that he'd keep his 5.3 going for as long as possible/practical (as long as there was demand for it of course) with backports etc.

I'd have stuck to the EL6 versions otherwise.

Picking a date out of the air, I'm thinking 12 to 24 months, maybe even 3 years, is the time to upgrade to a new version that has significant incompatibilities with older scripts.

Every PHP minor version upgrade seems to have backward incompatible changes. Whether they impact your clients depends on what software (and what specific versions) your clients want to run. I've seen software needing changes with every minor PHP upgrade so far.

I'm not sure Atomic will support PHP with backports for another three years, but you can always go back to the EL packages if you need to (we've done this in the past when we had to). Unless users start running code that requires features that were introduced after the version of PHP that EL6 is shipping at that moment (currently 5.3.3) of course. The support timeframe guarantee you get with Atomic is of course a bit less clear than the one you get from your EL distribution. As you mentioned, it also depends on the community demand. Maybe there could be a parallel add-on Atomic repository with php 5.4 packages for whoever wants to use them for instance, if there's enough demand?

I've not looked at the timeframes, but maybe by then we'll be looking at 5.6 or 5.8 (6.x?). ext/mysql will definitely be deprecated in 5.6 - and possibly removed completely.

The ext/mysql deprecation is in PHP 5.5.0 alpha 2 according to http://php.net/archive/2012.php#id2012-12-21-1

[scott]

How is an open transparent conversation of exactly the timeframe to support it "not clear".

[breun]

How is an open transparent conversation of exactly the timeframe to support it "not clear".

In the sense that there is no determined timeframe yet, as far as I know.

Please don't mistake my comments for bashing the Atomic PHP packages or something, we use them on a lot of servers and we love them. I'm just saying that if you want supported PHP 5.3 packages for as long as possible, I'd look at EL6's packages, since EL6 has support until November 2020.

[Highland]

I didn't mean to stir up a hornet's nest but I guess that's what happened.

A few comments

register_globals being removed is a major problem. A lot of code relies on this. Yes, BAD BAD BAD. But it does.

No major projects (Wordpress, etc) rely on it and it's been headed out the door since 4.2.0 I'd really hate to have to support any project still using it. The reason is pretty succinct on the PHP site.

When on, people use variables yet really don't know for sure where they come from and can only assume. Internal variables that are defined in the script itself get mixed up with request data sent by users and disabling register_globals changes this.

I honestly can't imagine writing code with this turned on, since you destroy variable scope. I'm seriously curious what kind of software would still need this. Do you run something custom that you can't touch?

safe_mode being removed Hmm...maybe a thread could be started specifically addressing this? With safe_mode gone, is running php via mod_php out of the window and everything has to be via fastcgi? (or mod_ruid2 or whatever)?

You can turn functions off in php.ini (and ASL can do this for your automatically). You can still use suPHP if you need strict controls on who can run what. I still run PHP as an Apache plugin and not FastCGI.

But that upgrade, whenever it happens, won't be to 5.4. I simply don't see anything in it that offers anything new that's actually useful to mainstream users compared to 5.3.

Compared to previous upgrades I've done, 5.3 to 5.4 was pretty easy. Very few changes to how it works but some very cool new features (Traits are awesome). The whole PHP 5.x series seems to have gotten a lot more stable (in terms of major changes) over time. I was a bit surprised by the new accelerated releases but I see that as a sign of maturity. Instead of making a bunch of giant changes they're making smaller releases to bring newer features out faster and that actually makes it easier to upgrade since you're not dealing with thousands of changes anymore (I think that's what helped to kill PHP 6). I listened to a talk by one of the main contributors on the failed PHP 6 project a couple of years ago and he explained that it was simply too ambitious (the main feature of PHP 6 was a move to UTF-16, which is scary for a lot of people, myself included). Most of the good ideas from PHP 6 went into 5.4 and some will come in 5.5 (like true type hinting).

I like new releases but I also have to support them and that's why I've had to hold back on 5.4 in-house until recently. I wasn't expecting 5.5 this soon or EOL on 5.3 but that's where I guess Zend is taking us. An 18 month release cycle. But, with smaller changes in between, it's manageable and it lets those of us who write code get the cool, new features without having to worry about everything breaking. If you're stuck with a massive legacy system, you have my sympathies (legacy support sucks), but there are ways to keep you happy without holding up everything else.

Maybe an atomic-legacy channel is in order? MySQL 5.6 isn't too far around the corner either...