# Please reconsider supporting PHP 5.2 - Thread: https://externals.io/message/49138 - Original archive: https://news-web.php.net/php.internals/49138 - Started by Karoly Negyesi on 2010-07-25T09:17:09+00:00 - Messages: 15 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #49138 — Karoly Negyesi — 2010-07-25T09:17:09+00:00 URL: https://externals.io/message/49138#49138 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. --- ## #49139 — Pierre Joye — 2010-07-25T09:37:58+00:00 URL: https://externals.io/message/49138#49139 · In reply to: #49138 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 --- ## #49140 — Karoly Negyesi — 2010-07-25T09:44:20+00:00 URL: https://externals.io/message/49138#49140 · In reply to: #49138 > > […] > 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 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 --- ## #49141 — Karoly Negyesi — 2010-07-25T09:49:10+00:00 URL: https://externals.io/message/49138#49141 · In reply to: #49140 > 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...? Sorry, apparently XCache 1.3 version does work with 5.3 it's only the homepage of it that does not mention this :) --- ## #49142 — Pierre Joye — 2010-07-25T09:50:21+00:00 URL: https://externals.io/message/49138#49142 · In reply to: #49140 hi, > > […] > > > […] > > Erm, you do realized that I copied that from the handbook page? Example: No, as you did not show any code and I was not sure what you meant exactly. Thanks to have clarified this case. > Also. It is not the EOL for 5.2. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #49143 — Reindl Harald — 2010-07-25T10:45:49+00:00 URL: https://externals.io/message/49138#49143 · In reply to: #49140 Am 25.07.2010 11:44, schrieb Karoly Negyesi: > > […] > > > […] > > Erm, you do realized that I copied that from the handbook page? Example: > > 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 Thanks god that tis happens to force developers to work clean `NULL` is not a reference so th real error os that such things ever worked > 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...? That is not a php-problem and http://eaccelerator.net/ works > Also note xdebug has a PHP 5.3 compatible release for less than a month. the question is not how long, the question is does it have --- ## #49144 — Reindl Harald — 2010-07-25T10:55:53+00:00 URL: https://externals.io/message/49138#49144 · In reply to: #49138 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 --- ## #49145 — Reindl Harald — 2010-07-25T12:06:12+00:00 URL: https://externals.io/message/49138#49145 · In reply to: #49138 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. --- ## #49146 — Pierre Joye — 2010-07-25T12:21:17+00:00 URL: https://externals.io/message/49138#49146 · In reply to: #49145 hi Reindl, > I really do not understand you Please do not top post and (re) consider the tone of your posts, in general. It could be a language barrier but we are here to discuss technical issues in the most friendly way. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #49147 — Kalle Sommer Nielsen — 2010-07-25T15:15:47+00:00 URL: https://externals.io/message/49138#49147 · In reply to: #49140 Hello 2010/7/25 Karoly Negyesi :' > 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...? You should check your sources better regarding APC, have a look at the APC 3.1.3: http://pecl.php.net/package-info.php?package=APC&version=3.1.3 Even before 5.3.0 was released, we worked on making APC compatible with 5.3 which was released only 1 month and 2 weeks after the release. Even the next release of APC thats going beta soon is having full support for the latest development branch (5.3.99). -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #49149 — Karoly Negyesi — 2010-07-25T15:24:49+00:00 URL: https://externals.io/message/49138#49149 · In reply to: #49147 I said 'stable'. Last I have seen http://pecl.php.net/package/apc the latest stable was 3.0.19. Regards Karoly Negyesi --- ## #49150 — Karoly Negyesi — 2010-07-25T16:05:10+00:00 URL: https://externals.io/message/49138#49150 · In reply to: #49145 > So this sounds like "bc does not interest me as long it affects > me personally" You have this backwards. BC surely interests me but there is no BC, there is only a pretense of BC so why not break it as we see fit? And because of this pretense I have asked not to stop supporting PHP 5.2. Regards Karoly Negyesi --- ## #49151 — Lukas Kahwe Smith — 2010-07-25T16:11:12+00:00 URL: https://externals.io/message/49138#49151 · In reply to: #49150 > > […] > > You have this backwards. BC surely interests me but there is no BC, > there is only a pretense of BC so why not break it as we see fit? And > because of this pretense I have asked not to stop supporting PHP 5.2. Arguing the same thing in circles is just wasting resources. Could stop your posts until you have something novel to post (and have thought it over and maybe spend a second to not look like a whiney user, but actually as someone who wants to contribute to improve the situation)? I read you are interested in QAing, so I suggest you check out http://qa.php.net/. Get setup to run at least the RC's (better yet also the alpha/beta releases, heck even the nightly snapshots) report your findings and assist the doc team in writing the migration guides. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #49153 — Larry Garfield — 2010-07-28T06:11:59+00:00 URL: https://externals.io/message/49138#49153 · In reply to: #49144 On Sunday 25 July 2010 05:55:53 am Reindl Harald wrote: > 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 > > > […] > > 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 One catch here is that `E_STRICT` implies no PHP 4 compatibility, as `E_STRICT` chokes on PHP 4-style class usage, etc. Drupal 6 had PHP 4 compatibility so `E_STRICT` was not an option. The core system was developed to `E_ALL` standards, but not all add-on modules (which are the lifeblood of any modular framework) are. I cannot speak for other projects but since Joomla, Wordpress, and CakePHP all were PHP 4-friendly until their most recent versions at least I suspect the story is much the same. I'm not disagreeing with you about writing pedantically correct code from the get-go (I've been a strong advocate of that in Drupal for quite some time), but when you have a code base that goes back nearly a decade and need to not lock out casual module developers who don't understand the intricacies of error level configuration and don't have root on their servers it's (unfortunately) not as simple a question as you make it out to be. That said, I'm actually against the removal of $foo(), not for BC reasons but because `call_user_func()` is *not* a viable replacement (it's actually considerably slower), $foo() is much easier to read (IMO), and because I've never once been confused by ::$ that I can recall. --Larry Garfield --- ## #49154 — Lester Caine — 2010-07-28T06:29:41+00:00 URL: https://externals.io/message/49138#49154 · In reply to: #49153 Larry Garfield wrote: > One catch here is that `E_STRICT` implies no PHP 4 compatibility, as `E_STRICT` > chokes on PHP 4-style class usage, etc. Drupal 6 had PHP 4 compatibility so > `E_STRICT` was not an option. The core system was developed to `E_ALL` standards, > but not all add-on modules (which are the lifeblood of any modular framework) > are. I cannot speak for other projects but since Joomla, Wordpress, and > CakePHP all were PHP 4-friendly until their most recent versions at least I > suspect the story is much the same. I came to the game JUST as PHP5 was creeping out into production, and so never ran PHP4 locally, however all of the projects I've been involved with have run happily on PHP4 and any code I've added has had to be compatible. It has taken several months to 'accommodate' PHP5.3, and some projects STILL will not run cleanly with it, so while people are pushing changes that THEY think are good ideas, please also bear in mind that PHP4 IS only just starting to be replaced, and PHP5. provides a cleaner base to move that code forward to! Now that we have 'lost' the target of PHP6, maintaining a stable platform for the time being is VERY important! Currently PHP5.2 is that stable platform. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php