Please reconsider supporting PHP 5.2

hi,

Hi,

A mere year after releasing Version 5.3.0 (Version 5.3.0 30-June-2009)
you are dropping PHP 5.2 support.

We still support 5.2.

There is a huge misunderstanding of "end of active support". It means
that only critical bugs (security related) will be fixed in 5.2. It
does not mean that 5.2 is not supported anymore.

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.

Not sure about this one. Do you have an example please?

The BC breaks are listed here (required changes due to bugs or bad behaviors) :

http://php.net/manual/en/migration53.php

Also, the deprecation of ereg will affect Drupal 6

Deprecation is only a message when and only when the error reporting
level is set to display deprecation messages. The deprecated functions
still work as before. Please see http://www.php.net/error_reporting

Then there is the date_default_timezone_set / date.timezone snafu.

It is now required as nobody read the manual. Without it you simply
expect date/time features to work correctly while relying on random
timezone or none at all.

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.

5 years is not too fast. Also again, it is not EOL. Distributions will
also take care of back porting what they have to for their releases
lifetime. But we can't. We don't have the resource nor the time to
maintain minor releases for 10 years. It is also important to notice
that clean code running well with 5.2 will run just as fine with 5.3
as well (yes, clean is all relative but I hope you understand my point
:).

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Where previously the function would accept the by-value argument, a
fatal error is now emitted.

Not sure about this one. Do you have an example please?

Erm, you do realized that I copied that from the handbook page? Example:

<?php
function a(&$x) {}
a(NULL);
?>
PHP Fatal error: Only variables can be passed by reference in
/var/www/u/sites/all/modules/awesomerelationships/x.php on line 4

Also.

Extensions. APC to this day does not have a stable release for PHP
5.3. Neither has XCache. I am not even sure how do you imagine
anyone much less everyone upgrading to 5.3 with a production site
without a stable code cache...?

Also note xdebug has a PHP 5.3 compatible release for less than a month.

Regards

NK

Am 25.07.2010 11:17, schrieb Karoly Negyesi:

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).

This is simply not true

A clean designed application has to run the whole time with
error_reporting = E_ALL | E_STRICT and so you should have seen
the problems long ago

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.

The problem is that the developers of drupal, joomla, wordpress
are not working error_reporting = E_ALL | E_STRICT as i do since
teh first day i use php even on production servers

While 122 installations of our own software throwing up to 10
warnings a month many other software rides a DOS-attack against mysql
if rsyslog is using a database

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.

Seems that you do not understand what deprecated means?
See that such calls are using a @ before to not make crazy
peopole like me with thousands of warnings and you have time
enough to clean your code

Then there is the date_default_timezone_set / date.timezone snafu.

If this is a problem the sysadmin did not his job
date.timezone = "Europe/Vienna" in php.ini exists
since years an dshould be set in all clan server setups

I really do not understand you

First you would like to see a incomatible change
without any sense because you do not like some code

On the other hand you are crying about the changes in 5.3
because your code which can not live with it since
you ignored warnings long time ago

So this sounds like "bc does not interest me as long it affects
me personally"

Am 25.07.2010 11:17, schrieb Karoly Negyesi:
[PHP-DEV] Please reconsider supporting PHP 5.2

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

Am 23.07.2010 00:54, schrieb Karoly Negyesi:
[PHP-DEV] Remove variable function and method calls

Given that call_user_func exists I would recommend to remove $foo()
from PHP Next.

Observe the "logic" in the following examples:

$foo();
new $foo();
classname::$foo;
classname::$foo();

There is a word for this and that word is madness.

The simplest is to nuke $foo(). call_user_func() is a perfect replacement.