# PHP 5.3.0RC4 - Thread: https://externals.io/message/44370 - Original archive: https://news-web.php.net/php.internals/44370 - Started by Lukas Kahwe Smith on 2009-06-19T08:50:37+00:00 - Messages: 13 - 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 --- ## #44370 — Lukas Kahwe Smith — 2009-06-19T08:50:37+00:00 URL: https://externals.io/message/44370#44370 Hello! we have packaged PHP 5.3.0RC4, which you can find here: http://downloads.php.net/johannes/ Windows binaries are available here: http://windows.php.net/qa/ This this release candidate focused on bug fixes and stability improvements and we hope to only require minimal changes ahead of the next release. Many, but not all, of the new features are already integrated in the official documentation on php.net. We aim to release PHP 5.3.0 next week. In case of critical issues we will continue producing weekly RCs. For most users there will not be a noticeable change meaning that now is the time to really do the final testing of PHP 5.3.0 before it gets released with any unnecessary incompatibilities with your project. Some additional links to get started: http://cvs.php.net/viewvc.cgi/php-src/NEWS?view=markup&pathrev=PHP_5_3 http://cvs.php.net/viewvc.cgi/php-src/UPGRADING?revision=PHP_5_3 Best Regards, Lukas and Johannes PHP 5.3 Release Managers --- ## #44371 — Lukas Kahwe Smith — 2009-06-19T09:16:18+00:00 URL: https://externals.io/message/44370#44371 · In reply to: #44370 > Hello! > > we have packaged PHP 5.3.0RC4, which you can find here: > http://downloads.php.net/johannes/ > > Windows binaries are available here: > http://windows.php.net/qa/ > > This this release candidate focused on bug fixes and stability > improvements and we hope to only require minimal changes ahead > of the next release. Many, but not all, of the new features are > already integrated in the official documentation on php.net. > > We aim to release PHP 5.3.0 next week. In case of critical issues we > will continue producing weekly RCs. For most users there will not be a > noticeable change meaning that now is the time to really do the final > testing of PHP 5.3.0 before it gets released with any unnecessary > incompatibilities with your project. We are really close, however there is obviously a steady stream of new tickets being opened [1]. Some of these include bugs in new functionality and some include BC breaks. At this point Johannes and I are not aware of any show stopper bugs yet though. We very much appreciate every effort to review those bug reports and as much testing as possible with real world applications. Please let us know ASAP if you do think that there is a show stopper bug. Also please do not commit to 5_3 without the explicit permission of Johannes. Please post any 5_3 patches to internals for peer review. We have had a few last minute commits break things and so we ask you to accept this additional step before commits for the hopefully short time period until 5.3.0 stable. Best Regards, Lukas and Johannes PHP 5.3 Release Managers [1] http://bugs.php.net/search.php?status=Open&phpver=5.3&cmd=display --- ## #44372 — Richard Quadling — 2009-06-19T09:24:41+00:00 URL: https://externals.io/message/44370#44372 · In reply to: #44371 2009/6/19 Lukas Kahwe Smith : > [1] http://bugs.php.net/search.php?status=Open&phpver=5.3&cmd=display Is there a reason why http://bugs.php.net/bug.php?id=47918 is not in that list? Regards, Richard. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #44373 — Pierre Joye — 2009-06-19T09:28:34+00:00 URL: https://externals.io/message/44370#44373 · In reply to: #44372 hi, It is set as: "5.*, 6CVS (2009-04-07)", does not match "5.3". Cheers, On Fri, Jun 19, 2009 at 11:24 AM, Richard Quadling wrote: > 2009/6/19 Lukas Kahwe Smith : > > […] > > Is there a reason why http://bugs.php.net/bug.php?id=47918 is not in that list? -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #44374 — Uwe Schindler — 2009-06-19T10:13:50+00:00 URL: https://externals.io/message/44370#44374 · In reply to: #44370 Hallo, I just wanted to compile PHP 5.3.0RC4 on my Solaris 10 box: pangaeaw@pansrv1:~/install/php-5.3.0RC4$ gcc -v Reading specs from /opt/csw/gcc3/lib/gcc/i386-pc-solaris2.8/3.4.5/specs Configured with: ../sources/gcc-3.4.5/configure --prefix=/opt/csw/gcc3 --with-local-prefix=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-shared --enable-multilib --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib --enable-languages=all Thread model: posix gcc version 3.4.5 and got a compilation failure: /bin/sh /pangaea/install/php-5.3.0RC4/libtool --silent --preserve-dup-deps --mode=compile gcc -I/pangaea/install/php-5.3.0RC4/ext -I -Iext/pdo_mysql/ -I/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/ -DPHP_ATOM_INC -I/pangaea/install/php-5.3.0RC4/include -I/pangaea/install/php-5.3.0RC4/main -I/pangaea/install/php-5.3.0RC4 -I/pangaea/webserver70/include -I/pangaea/install/php-5.3.0RC4/ext/date/lib -I/pangaea/install/php-5.3.0RC4/ext/ereg/regex -I/opt/csw/include/libxml2 -I/opt/csw/include -I/pangaea/install/php-5.3.0RC4/ext/mbstring/oniguruma -I/pangaea/install/php-5.3.0RC4/ext/mbstring/libmbfl -I/pangaea/install/php-5.3.0RC4/ext/mbstring/libmbfl/mbfl -I/opt/csw/mysql5/include/mysql -I/usr/include/libxml2 -I/pangaea/install/php-5.3.0RC4/TSRM -I/pangaea/install/php-5.3.0RC4/Zend -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/opt/csw/include -g -O2 -DZTS -c /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c -o ext/pdo_mysql/mysql_statement.lo /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function `pdo_mysql_stmt_dtor': /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:52: error: structure has no member named `stmt' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:70: error: structure has no member named `params' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:71: error: structure has no member named `params' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:73: error: structure has no member named `in_null' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:74: error: structure has no member named `in_null' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:76: error: structure has no member named `in_length' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:77: error: structure has no member named `in_length' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function `pdo_mysql_stmt_set_row_count': /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:127: error: structure has no member named `stmt' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function `pdo_mysql_stmt_execute': /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:295: error: structure has no member named `stmt' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function `pdo_mysql_stmt_describe': /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:678: error: structure has no member named `stmt' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function `pdo_mysql_stmt_get_col': /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:727: error: structure has no member named `stmt' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function `pdo_mysql_stmt_col_meta': /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:831: error: structure has no member named `stmt' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function `pdo_mysql_stmt_cursor_closer': /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:898: error: structure has no member named `stmt' gmake: *** [ext/pdo_mysql/mysql_statement.lo] Error 1 Is this a known bug? Uwe ----- Uwe Schindler thetaphi@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany > -----Original Message----- > From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org] > Sent: Friday, June 19, 2009 10:51 AM > To: internals@lists.php.net; php-general@lists.php.net > Subject: [PHP-DEV] PHP 5.3.0RC4 > > Hello! > > we have packaged PHP 5.3.0RC4, which you can find here: > http://downloads.php.net/johannes/ > > Windows binaries are available here: > http://windows.php.net/qa/ > > This this release candidate focused on bug fixes and stability > improvements and we hope to only require minimal changes ahead > of the next release. Many, but not all, of the new features are > already integrated in the official documentation on php.net. > > We aim to release PHP 5.3.0 next week. In case of critical issues we > will continue producing weekly RCs. For most users there will not be a > noticeable change meaning that now is the time to really do the final > testing of PHP 5.3.0 before it gets released with any unnecessary > incompatibilities with your project. > > Some additional links to get started: > http://cvs.php.net/viewvc.cgi/php-src/NEWS?view=markup&pathrev=PHP_5_3 > http://cvs.php.net/viewvc.cgi/php-src/UPGRADING?revision=PHP_5_3 > > Best Regards, > Lukas and Johannes > PHP 5.3 Release Managers --- ## #44378 — Lester Caine — 2009-06-20T06:49:43+00:00 URL: https://externals.io/message/44370#44378 · In reply to: #44370 Lukas Kahwe Smith wrote: > Some additional links to get started: > http://cvs.php.net/viewvc.cgi/php-src/NEWS?view=markup&pathrev=PHP_5_3 > http://cvs.php.net/viewvc.cgi/php-src/UPGRADING?revision=PHP_5_3 While I know that ... - All ereg functions are deprecated and emit `E_DEPRECATED` errors. Use PCRE (preg_*()) instead. ... is accurate, I think a little more detail would help here, since many of us probably did not know that 'split' was an ereg function - for instance? I THINK that split() maps to `explode()` without needing any mapping of the parameters? But ereg_replace to preg_replace is not quite so easy? and when looking to convert someone else's legacy code, trying to understand some mappings can be a problem. Does anybody have a useful reference that would help in converting from one to the other? 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 --- ## #44379 — Keisial — 2009-06-20T14:18:31+00:00 URL: https://externals.io/message/44370#44379 · In reply to: #44378 Lester Caine wrote: > Lukas Kahwe Smith wrote: > > […] > > While I know that ... > - All ereg functions are deprecated and emit `E_DEPRECATED` errors. > Use PCRE (preg_*()) instead. > > ... is accurate, I think a little more detail would help here, since > many of us probably did not know that 'split' was an ereg function - > for instance? > > I THINK that split() maps to `explode()` without needing any mapping of > the parameters? split() splits a string using a regular expression. `explode()` splits using a fixed string. While it's likely many people is using split() for cases where `explode()` should be used*, usages really using regex can't be replaced by `explode()` (preg_split() is the equivalent function... with the other regexes) *Including one in the split manual page. --- ## #44380 — johannes@schlueters.de — 2009-06-20T23:25:26+00:00 URL: https://externals.io/message/44370#44380 · In reply to: #44374 Hi, > /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function > `pdo_mysql_stmt_dtor': > > /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:52: error: > structure has no member named `stmt' Which MySQL client libraries are you using? Looks like 4.0 or older. I'll check whether I can fix those, while MySQL 4.1 was released in 2004 and MySQL's active support for 4.0 ended 2006, which means it's rather old software... johannes --- ## #44381 — johannes@schlueters.de — 2009-06-20T23:36:42+00:00 URL: https://externals.io/message/44370#44381 · In reply to: #44378 > While I know that ... > - All ereg functions are deprecated and emit `E_DEPRECATED` errors. > Use PCRE (preg_*()) instead. > > ... is accurate, I think a little more detail would help here, since > many of us probably did not know that 'split' was an ereg function - for > instance? hm, the las version on the wiki listed them ... In general: I'd like if people could come up with more details and add them to the docs. (See Rasmus's mail) So that this file is as short as i makes sense so people have a chance to be aware of as much contents as possible - and isn't scared away. johannes --- ## #44384 — Lukas Kahwe Smith — 2009-06-21T08:10:57+00:00 URL: https://externals.io/message/44370#44384 > Johannes Schlüter wrote: > > […] > > I was probably looking more for pointers to some extra information. > Part of the problem here is that the warnings are being thrown in > code that *I* did not write, so then one either has to search for > updated versions of a library or work out how to fix them yourself - > where I'd 'borrowed' the code originally. Simply hiding `E_DEPRECATED` > is likely to lead to even bigger blowups later? :( Actually `E_DEPRECATED` is only something you should enable temporarily. Then you can alert either your own team, or the project who's code you are using and move on. It simply tells you that the code will break with the next major version. This is not an end of world fatal error. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #44386 — Lukas Kahwe Smith — 2009-06-21T08:29:42+00:00 URL: https://externals.io/message/44370#44386 > Lukas Kahwe Smith wrote: > > […] > > On a production site - probably - but I see no reason to disable it > on the development sites. It's all to easy to grab a bit of code and > drop it in, forgetting that it's now on the 'deprecated' list. I > avoid libraries that throw errors and will only work with > 'display_errors=off'. If I need to use them then I will fix any > errors even if 'non-fatal' before using the code in production! So > before PHP5.3 is acceptable for production, any warning needs to be > addressed - at least in my book. There is a reason why `E_DEPRECATED` isn't part of E_ALL. Anyways, its your call, but its not what we suggest. But overall there is always room for doc improvements (feel free to help out), but in the end you need to know the code or familiarize yourself with the code if you want to "fix" it, though per se .. there is nothing broken with the code in the current version of PHP. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #44387 — Lukas Kahwe Smith — 2009-06-21T09:48:20+00:00 URL: https://externals.io/message/44370#44387 · In reply to: #44386 > > > > > […] > > > There is a reason why `E_DEPRECATED` isn't part of E_ALL. Anyways, its > your call, but its not what we suggest. But overall there is always > room for doc improvements (feel free to help out), but in the end > you need to know the code or familiarize yourself with the code if > you want to "fix" it, though per se .. there is nothing broken with > the code in the current version of PHP. Ok, guess I am wrong here. Its part of `E_ALL` as I suggested it when I proposed `E_DEPRECATED` initially. Since it seems I was the only one that considered not including it in E_ALL. That being said, for development we currently suggest: error_reporting = `E_ALL` | `E_STRICT` And for production: error_reporting = `E_ALL` & ~E_DEPRECATED So I guess we are pushing people towards fixing deprecation issues a bit more forcefully than I thought. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #44390 — Lester Caine — 2009-06-21T10:58:48+00:00 URL: https://externals.io/message/44370#44390 · In reply to: #44387 Lukas Kahwe Smith wrote: > > […] > > Ok, guess I am wrong here. Its part of `E_ALL` as I suggested it when I > proposed `E_DEPRECATED` initially. Since it seems I was the only one that > considered not including it in E_ALL. > > That being said, for development we currently suggest: > error_reporting = `E_ALL` | `E_STRICT` > > And for production: > error_reporting = `E_ALL` & ~E_DEPRECATED > > So I guess we are pushing people towards fixing deprecation issues a bit > more forcefully than I thought. I must say that is does annoy me when I download a PHP package to have a look at, and since my systems all run with display_errors=on, these packages are somewhat unusable because of various warning messages. Ignoring messages like these is simply pointless - they should be handled and cleared up - which is why SOME of the decisions on what will be removed causes a lot of agro to which "Just switch it off!" is NOT an adequate response? We ARE expected to fix these things since that is what the people who pushed the changes through expect to happen anyway so that they can be removed quicker? :( -- 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