Please reconsider supporting PHP 5.2

Hi, A mere year after releasing Version 5.3.0 (Version 5.3.0 30-June-2009) you are dropping PHP 5.2 support. This is a very interesting decision as 5.3.0, compatibility wise, is a major release. I always felt it was PHP 6.0 but it was not called so because there was a development branched called that (which was later abandoned). Serious BC breaking changes include Where previously the function would accept the by-value argument, a fatal error is now emitted. This broke Drupal 6 big time and while core has been fixed, contrib is a bit slower to adapt. Previously, it was possible to pass in simply NULL if you did not care about the by-reference argument. Also, the deprecation of ereg will affect Drupal 6 over its lifetime as the module install / enable functionality uses ereg in a way that can't be fixed: as it is not on a performance critical code path noone bothered to rewrite the truly ancient directory scanning function which takes an ereg as it's argument earlier. And we can't break APIs in a minor release so this can only change in Drupal 7 which is poised to be released in a few months. CakePHP had problems with PHP 5.3 http://i.justrealized.com/2009/08/16/cakephp-php-deprecated-error-warning/ and while I am not sure whether these problems got fixed or not, one year is not a lot of time and so anyone happening to use older CakePHP for whatever reasons is toast. Joomla had its share of problems http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=17150 but they are fixed now, yes. I can repeat what I said about forcing new versions. Then there is the date_default_timezone_set / date.timezone snafu. While as a Drupal core developer I am _so eager_ to use closures finally I can't really endorse forcing everyone to switch to another major version a mere two years after EOLing PHP4. That's fast... too fast. Kind regards Karoly Negyesi Disclaimer: this email only reflects my own personal opinion. Even if that.