Migrating to PHP5: a sensible solution at last?

As everybody in the php world is bound to know, PHP4 is still the dominant platform on the net, despite its age and many shortcomings. Notwhistanding many improvements in speed, security and functionality, PHP 5 has seen so far a less-than-stellar adoption rate.

PHP adoptions stats by nexen.net

There have been a lot of discussions in the blogosphere about this “problem”, with the most basic explanation being:

  • web hosters do not upgrade because some very successful web apps (blogs, cms, bulletins, etc…) still need php 4 to run
  • php coders have to code for php 4 because otherwise they loose the opportunity of getting deployed on shared hosting
  • since the apps run on php 4 anyway, why upgrade? (a classic case of dog-eats-tail)

Other people refer to PHP as victim-of-its-own-success: PHP 4 was good enough for everybody, so a lot of people do not feel compelled to upgrade.

While I am generally in favour of extreme ABInex and API stability (I have servers running php 4.0.4, pl1 mind you…), I have to admit that the current situation imposes a heavy burden on the developers of php libraries and applications: the coder has to cater to the quirks and bugs of every possible php version, and either avoid any enhancement that has seen the light roughly in the last 5 years (since the release of php 4.2) or resort to provide alternative code paths for the less-fortunate (the php-compat package on Pear is a great help if you’re into defensive coding).

The best proposal I have seen so far to this situation comes from the Drupal mailing list:

PICK A DATE FOR PHP 4 DESUPPORT AND ANNOUNCE IT TO THE WORLD WITH ENOUGH ADVANCE.

The chosen date has to be agreed upon by most major php application teams (this is the hard part), but most of them, have been planning the upgrade to php5 anyway.

  • The hosters and sysadmins at private companies will be given enough time to test the deployment of the new php version
  • The developers will feel the need to make sure that their app runs fine on php 5 before the cutover date
  • Everybody will be happy (except Stefan Esser, he never is…)

One last question remains open: WHAT SHALL WE CALL THE DAY THAT PHP4 IS PUT TO REST?

Suggestions are welcome…

3 thoughts on “Migrating to PHP5: a sensible solution at last?”

  1. OK, you’ve pointed out a problem, with a nice exposition of the principal pros and cons … but what is YOUR proposed date ?

    Based on what elements ? Now I’ll sit and wait for your reply 😀

  2. Well, duh, I have no idea!

    First of all, I do not maintain any large and famous php application.
    Then, I am an engineer, and I lack any serious sense of humour to pick decent names.

    I would suggest the 1st of april of next year, though:
    – is enough far away for everybody to adapt
    – if it does not work out, we can always say it was meant as a joke from the beginning 😉

Leave a Reply

Your email address will not be published. Required fields are marked *


Warning: Declaration of sk2_pjw_simpledigest::output_plugin_UI() should be compatible with sk2_plugin::output_plugin_UI($output_dls = true) in /membri2/gggeek/wp-content/plugins/SK2/sk2_plugins/sk2_pjw_daily_digest_plugin.php on line 277

Warning: Declaration of sk2_captcha_plugin::output_plugin_UI() should be compatible with sk2_plugin::output_plugin_UI($output_dls = true) in /membri2/gggeek/wp-content/plugins/SK2/sk2_plugins/sk2_captcha_plugin.php on line 84

Warning: Declaration of sk2_rbl_plugin::treat_this($cmt_object) should be compatible with sk2_plugin::treat_this(&$cmt_object) in /membri2/gggeek/wp-content/plugins/SK2/sk2_plugins/sk2_rbl_plugin.php on line 342

Warning: Declaration of sk2_referrer_check_plugin::output_plugin_UI() should be compatible with sk2_plugin::output_plugin_UI($output_dls = true) in /membri2/gggeek/wp-content/plugins/SK2/sk2_plugins/sk2_referrer_check_plugin.php on line 92