It seems to be that

a) Webhosts should keep their PHP versions to the latest stable version, mainly for security, but secondly for bug fixes and to take advantage of new features. PHP 5.2 came out in November last year and thus is PHP 5.2.0 - 5.2.3 would be my current description for up to date.

b) The only reason for keeping back is that scripts known to work on 5.0/5.1 may not work with 5.2, and there's time involved in testing this (we know this full well, we have a server in this state).

c) Therefore we should encourage (but not require) those installing SilverStripe to use PHP 5.2, so that SilverStripe runs as securely and bug-free as possible, and as a bonus, allows us to make use of the (minor as I see it) new features.

I see this done as a notice in the installer saying phrases like "we encourage using 5.2 for SilverStripe... your version of PHP is old, buggy and insecure ... your current version will work now, however later versions of SilverStripe may not work unless you upgrade to 5.2"

d) With the view that by February 5, 2008, SilverStripe will altogether officially drop support for PHP 5.0/5.1, which specifically means not testing it on those versions, and using code that is known to break on those versions.

e) Its important to realise that SilverStripe's minimum version is slowly increasing anyway, as we find major use of functions or code that breaks due to PHP bugs. For instance, PHP 5.0.3 had a number of bugs where we decided not to deal with, and instead say "upgrade" to. So, I feel we're essentially doing (e) without realising it, but it is healthier for us to definitively act on this, and encourage use of installing SilverStripe of PHP 5.2 webhosts so that we can make use of it.

f) As a side note, one major reason large packages (anything from SilverStripe1 or Drupal) get themselves into trouble is through holding onto an old version. By incrementally lifting the minimum PHP version, it will be easier to eventually make use of PHP 5.3 or 6.0 features, so this is all part of a long term strategy of keeping SilverStripe in the lead.

See PHP 5 Changelog: http://www.php.net/ChangeLog-5.php

Oh, so my take on the actual improvements in 5.0 to 5.1??

Many people are touting a few killer features that are reason to upgrade. I disagree.

Instead, I see a thousand small improvements that collectively work together in lieu, and add up to the same benefit of, a 'killer feature'. This is why I believe PHP 5.2 upgrades should occur.

The supposed 'killer features' could have well be left out, and my notion of upgrading to get all the other fixes and improvements would still be as true.

- JSON can be done in PHP 5.0/1. So... PHP 5.2 only makes it faster (and currently buggier from our experience).
- PDO, which we hope to use shortly to allow multiple database support, also works in PHP 5.0
- The filter extension seems to provide no new functionality; you now have a consistent way of writing long-winded input data checking instead of an inconsistent way of doing it. They should have built it with OO and made the error messages a part of the system, then I'd be blogging about how wonderful it is. See jsuchal's great code ideas at
http://devzone.zend.com/node/view/id/1113

I'd like for others to comment, especially in highlighting what new code DOES actually bear significance.

I posted this to the New Zealand PHP mailing list, and so far the only interesting information is PHP 5.2's __toString method

which as explained at http://www.onekay.com/blog/archives/14, states up till 5.2 __toString() was only called when the object was sent to echo or a print() - now you can throw the object around anywhere that would cast the object to a string, and have it call the __toString() method:

CODE:

   1.      // concatenation
   2.      $string = 'foo'.$barObject;
   3.       
   4.      // casting
   5.      $string =  (string) $object;
   6.       
   7.      // functions & language constructs
   8.      // which take strings as arguments
   9.      try
  10.      {
  11.      $foo = new Foo();
  12.      echo htmlentities($foo);
  13.      }
  14.      catch (FooException $e)
  15.      {
  16.      die($e);
  17.      }