uhm i dont see the problem. even drupal 6 works with 5.3. why does one have to go to 5.2 first? you can jump straight from 5.1 to 5.3. sure would be nice if each of the projects would more actively monitor php.net (making whats going inside php.net more transparent is not easy unfortunately, i got tired of the up hill battle).

So is PHP community moving too fast or is WP/Drupal/etc adopting too slow?

From what you’re saying it looks like PHP is living in a little different reality than the rest of the world.

That brings me a picture where Toyota (PHP community), encouraged by Green Peace and electronics/batteries manufacturers (frameworks devs and early adopters), wants to push Prius to customers (WP/Drupal) in a world where gas prices are $0.95/gallon and everyone wants to drive SUVs and pickup trucks. So they’re saying “From now on no more Highlanders, Tundras and FJs. Prius is your only choice”.

And than Toyota community becomes a second Cuba with 50 years old cards fixed with duct tape

“The real issue at hand, however, is the fact that these large user communities are not engaged in the PHP world, and vice-versa.” Actually, I think the “vice-versa” part is not the issue at all. The PHP core developers strive very hard to retain backwards compatibility between the minor releases, and have very clear, concise changelogs to aid those migrating from one version to the next. Even for large projects, it should not take long to upgrade from one version of PHP to the next. (For perspective, when updating ZF to be compatible with 5.3, my team spent a matter of a couple of days to make the entire codebase compatible.)

I do agree with the other side of the statement, however. At the heart of the issue is that the developers of these popular applications are not looking hard at the language and how it is evolving; many appear to have blinders on to any version other than the one they originally built the application on. This is tremendously short-sighted, particularly in the open source world where resources for maintaining older versions over the long term are very limited. They also do a dis-service to the entire PHP community when doing so, as the popularity of their applications dictate what versions of PHP will be available on shared hosting providers — crippling those who are trying to use anything more recent.

@Lukas: It’s more an issue with the ISPs I think. I recently had a project that required 5.3 and it took the hosting provider nearly a month to respond to my request to upgrade, and this was for a dedicated server. If it was for one of their shared servers I would have been out of luck. 5.2 has been included in most of the major server OS installs for awhile now, so it’s more widely distributed. Given how important it is for things like Drupal/WP to just work in the majority of cases, they usually can’t count on having the latest & greatest environment.

Two things:

1. It is not EOL but end of active support.
What does it mean? Only security fixes will get in and EOL will follow later (say within a year or so).

2. Good code will work smoothly with 5.2 and 5.3. Projects still trying to target php 4.x and 5.x are simply out of luck (if I can call that ‘luck’, I would prefer to use the word ‘sanity’ instead).

All in all it is a non issue, drupal or the major other frameworks proove it, good code base allows to support 5.2 and 5.3 easily.

Marco, PHP 5.2 was released 2006-11-02. It is almost four years since that date now. It is a problem of WP developers with their sluggish PHP4-like code, that for four years they were not able to move to 5.2 yet. Are you saying, that 4 years is not enough to release a new version of the language? Look at .NET and how it evolves.

Also, WP perfectly works on 5.3, so what’s the problem? EOL does not break anything. May be in another four years WP guys will move to 5.3…

Some major frameworks now (look at Symfony for example) require PHP 5.3. ZF requires 5.2.4 at least.

EOL does not break anything, except future progress. Let’s continue using WordPress as an example. They released 3.0 a few weeks ago. If they’d decided to make 3.0 a PHP 5.3-only application, they would have a huge PR problem. Because maybe a quarter of their users could take advantage of the new things in WP 3.0.

So you tell your web host “I need you to upgrade to PHP 5.3 so I can upgrade my WordPress to the latest and greatest.” And the web host will say “Nope, can’t do it. I have a hundred clients running XYZ Application, which doesn’t work at all on 5.3.”

After a few dozen episodes like that, the community backlash would mount. “You promised us multi-user functionality in 3.0, and we can’t use it because you used a namespace to implement it??? How stupid!”

Yeah, the tail-chasing continues. Should the application developers just take the beating and move on? Might be one solution, but as an application developer myself, I’m not a huge fan.

The disconnect between PHP and “its downstream projects” is not our problem. From my (limited) interaction with communities such as WordPress, Drupal, Joomla etc. they do not see themselves as part of the “PHP ecosystem” and their developers and users do not refer to themselves as “PHP developers” but rather as “Drupal developers” etc.

Just like any of the downstream projects, PHP is built by volunteers. These volunteers should not have to waste their limited resources to maintain old versions of PHP.

And, btw, funny that you mention WordPress and PHP 5.2 in the same context. WordPress is still compatible with PHP 4. Is that what you mean by “push support for 5.2 into their products”?

Well, PHP 5.2 is going to be a requirement in WordPress 3.2 according to the announcement today.

The big problem with 5.3 is all the deprecated stuff throwing warnings. Pretty sure WP is currently 5.3 compat beyond that.

Back when I developed OSS the idea was always to be future compatible without making use of those features that would break backwards compatibility. In some cases implementing things both ways. I see no reason why WP can’t say they’re 5.3 compatible without making use of 5.3 specific features! In order to ease development they have to eventually stop supporting old platforms. Do they really expect to fix bugs on PHP 4 at the same priority they do for PHP 5.2? They should phase out PHP 4 support (most hosts have 4 and 5 side by side), make it compatible with PHP 5.3, then in a few years phase out 5.2 support completely, so they can make use of PHP 5.3 features. But, IMO from looking at Drupal and WP’s code, I doubt either of them really care about using the latest language features. They’re content with their hacks.

@Sebastian:

Statements like this – The disconnect between PHP and “its downstream projects” is not our problem. – will ensure that these communities work without regard to and sometimes in spite of the core PHP community. After all, what is the benefit to them?

@keith

Just like asking what is the benefits for you to test RCs with your softwares, to ensure that you get the best out of PHP or that PHP fixes or changes did not break your apps inadvertently.

For one I do try to create bridges between projects using PHP and PHP Core, as much as possible. That’s the only to ensure success, for both. Especially when it comes to identify needs and issues in the languages, its extensions, etc.

Because maybe a quarter of their users

Josh said “maybe a quarter” of WordPress users can take advantage of 5.3. Here’s some numbers:

3.56% of WordPress installs currently run on PHP 5.3. Meanwhile, 85.06% are on PHP 5.2. There are more users on 4.4, and more users on 5.1, than there are on 5.3. We have to follow adoption of our users, and here’s it’s a no-brainer.

As long as main Linux distributions will keep providing old PHP versions (RHEL 5 PHP is still 5.1.6) you’ll have isv and users that will use them. Not because they like this version but because they don’t have the choice.

My reason for not upgrading to 5.3 is that Zend Optimizer does not seem to work in 5.3. I have a client with files that were encoded with Zend Guard years ago. I can’t upgrade to 5.3 or that client’s site will stop working.

@Jim check out the 5.3 Loader versions at http://forums.zend.com/viewtopic.php?f=57&t=6595, post in that forum (not here) if you have questions.

@Sebastian “Just like any of the downstream projects, PHP is built by volunteers. These volunteers should not have to waste their limited resources to maintain old versions of PHP.”

Are you from outer space or just a little bit ignorant?

The majority of PHP end-users, are those downstream project users!

Sure php developers should not waste their precious time in supporting large numbers of end users. Why would they, it’s not their fault that the downstream project can’t keep up with the fire arrow alike movements of the php developers. (Cancellation of PHP6, sudden remove of PHP5.2 support, NO UTF8, YES UTF8, oh sorry NO UTF8 again etc. etc.)

Common, get real people… try communicating upfront, in public instead of mailing lists, with those end users instead of sitting on your own island.

The power of PHP lies for a big part in those downstream projects, and un announced moves like these are really bad for the enterprise ready name PHP is trying to get. I say trying, cause i can assure you that doing things like this is not going to help a language become enterprise accepted.

Enterprise maintainers and system administrators simply can not afford to upgrade a entire ecosystem just because a bunch of developers suddenly decide they can not waste their oh so precious time on a supporting a ‘ancient’ language, and like to introduce new features that throw nice warnings at the end user that something is deprecated.

Having said this, i agree that some downstream project are ignorant to, common support for php4 should not be in a modern project. PHP4 is dead.. but really dead!

However this method of forcing projects to PHP 5.3, by stopping active support for 5.2 and stating that security is going to fixed if developers find the need for it.

Sure i can understand the reasons. And i’am upgrading my projects as well, cause i do see the advantages of PHP 5.3. (especially the PHP-FPM including in 5.3.3)

As I understand it, PHP5.2 has been around for a while now and if WP et al are unable to maintain the status quo by moving with the times then tough.

My hosts are moving to PHP5.3 from PHP5.2 and about time too IMHO – why should the world stop for WP et al? Wouldn’t we all be well screwed if we followed the (bad) practices of the mortley WP crew?!

F@@@ them [WP et al] I say…

Why drag Drupal into this?

Drupal and other CMSes need to run on a large variety of hosts.

Drupal 7 runs on 5.3 just fine. 5.2 is simply the minimum requirement.

I’m hearing way too much ‘not our problem’ from people who are directly involved with the future of PHP. That is a bit disappointing, because although your arguments are perfectly valid, your approaches do not qualify you as ambassadors to the language. Whether you want that title or not, it doesnt matter, because as the most public faces of PHP, you are by your actions either attracting developers or shunning them.

Just sayin.

This may actually help adoption of 5.2 on some platforms. At present 5.1.6 is considered the production release for CentOS. This annoys me to no end, but now that 5.2 will only be updated for security reasons it stands to reason that the next release of CentOS will support it since it is feature-frozen.

While many of us knee-deep in PHP land can’t fathom running older releases, this is likely a good thing to move along the glacier of supported releases. It is good that someone is conservative in what release point they support.

“The real issue at hand, however, is the fact that these large user communities are not engaged in the PHP world,”

“However, PHP development is too unevenly connected to downstream adopters. Some—particularly framework makers—have an unusually high level of participation in deciding how PHP evolves, and that needs to change.”

That doesn’t mean fw makers should participate less, it means that large user communities like Drupal, WordPress, etc should participate more.

“Common, get real people… try communicating upfront, in public instead of mailing lists, with those end users instead of sitting on your own island.” (Rene)

How is a _public_ mailinglist/newsgroup not public? Everybody is able to follow discussions on news.php.net/php.internals, and get involved as he/she wishes.

Drupal and WP strive for a broader target market. And market reality just is that most hosting providers haven’t migrated to PHP 5.3 yet, nor will they till the end of the year. It’s no failure of downstream application developers not to force version upgrades. Obviously it’s easier to rely on established PHP support than to deal with incompatibility woes and user complaints.

If PHP.net developers want to deal out blame, there’s a good point to start. Neglecting proper language design and 5.3 support for APC et al contributes to the slow adoption curve. Unasked for semantic and questionable syntax changes in point releases (!) don’t help either. And API compatibility is not seldomly hampered by random new parameters for established base functions. Avoidance is a good strategy if spurious development bumps that simply trouble your user base.

I don’t believe php.net is able to fix its hen and egg version progress problem. Their point release feature onhobbling strategy clearly failed.

Giving the limited amount of backward incompatibilities in PHP 5.3, I don’t really see a problem in ending PHP 5.2 development. Testing for PHP 5.3 compatibility can be somewhat automated as well through a set of CodeSniffer rules I wrote (see http://github.com/wimg/PHP53Compat_CodeSniffer), although it doesn’t cover everything ofcourse.
If we want to get rid of the version fragmentation in the PHP hosting world, we need to either make sure that multiple versions of PHP can run within a single environment (which can be tricky and too challenging for most hosting providers) or force people to keep updated at least to the minor releases (arguably this should be called a major release since we’re not getting PHP 6 anytime soon).
Anyone arguing that a x.x.3 release is ‘not enough releases’ to ensure “it’s stable enough” should look at the release date (5.3.0 was released in June 2009) and how many large hosts have been running PHP 5.3 for almost a year now.
Let’s not forget the very nature of PHP is that it follows whatever the market needs as quickly as possible. If hosting providers don’t keep up with what the market needs, they will loose customers. So upgrading to PHP 5.3 should be a priority for them, perhaps not on all their servers (some customers might have incompatible code after all), but at least on some.

“However, PHP development is too unevenly connected to downstream adopters. Some—particularly framework makers—have an unusually high level of participation in deciding how PHP evolves, and that needs to change.”

@Marco:

IMO, framework developers are doing a good job here. If anything, it showcases the tenacity and devotion of the framework developers to provide a quality product rather than a product that “just works”.

Don’t get me wrong, a product that works is a great feat (unfortunately) for a lot of shops; however, I do not believe it should be the final goal.

“…in public instead of mailing lists, with those end users instead of sitting on your own island.”

@Rene:

From what I gather, you are saying that because “you” and certain others do not care to utilize the _very_ _public_ resources available, these resources are somehow deemed _non-public_? I do not believe that is fair.

There are also plenty of commercial closed-source software and hardware products that use the same facilities to allow their users to congregate. In some cases they even charge for access. PHP provides this for free. Why is this not enough?

“Drupal and WP strive for a broader target market…”

@Mario:

Thus they allow the popularity contest to dictate the progress of their product. A better approach might be to make the software:

1: easy to upgrade
2: easy to maintain
3: and most importantly, easy to extend (‘extend’ !== ‘ugly hack’)

I doubt this would make them less popular with their target market.

I personally wouldn’t want to think that my software was popular only because it works with a majority of hosts. Kind of a cop-out goal that reeks of mediocrity.

“Unasked for semantic and questionable syntax changes in point releases (!) don’t help either.”

@Mario:

So, because “you” don’t need it, no-one else does? I would recommend that you check out python, scala, .net, and ruby sometime. No, PHP isn’t python, scala, .net, or ruby, but that doesn’t mean PHP should close its eyes and pretend that there aren’t good ideas out there that can be leveraged to make PHP even better.