Re: [PHP-DEV] PHP 5.3.0RC4

[Lester Caine]

Lukas Kahwe Smith wrote:
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.


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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.3.0RC4

[Lukas Kahwe Smith]

On 21.06.2009, at 10:29, Lukas Kahwe Smith wrote:



On 21.06.2009, at 10:24, Lester Caine wrote:


Lukas Kahwe Smith wrote:

On 21.06.2009, at 09:51, Lester Caine wrote:

Johannes Schlüter wrote:

On Sat, 2009-06-20 at 07:49 +0100, Lester Caine 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?

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.


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.


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.



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
m...@pooteeweet.org




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.3.0RC4

[Lukas Kahwe Smith]

On 21.06.2009, at 10:24, Lester Caine wrote:


Lukas Kahwe Smith wrote:

On 21.06.2009, at 09:51, Lester Caine wrote:

Johannes Schlüter wrote:

On Sat, 2009-06-20 at 07:49 +0100, Lester Caine 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?

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.


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.


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
m...@pooteeweet.org




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.3.0RC4

[Lester Caine]

Lukas Kahwe Smith wrote:


On 21.06.2009, at 09:51, Lester Caine wrote:


Johannes Schlüter wrote:

On Sat, 2009-06-20 at 07:49 +0100, Lester Caine 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?

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.


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.


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.


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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.3.0RC4

[Lukas Kahwe Smith]

On 21.06.2009, at 09:51, Lester Caine wrote:


Johannes Schlüter wrote:

On Sat, 2009-06-20 at 07:49 +0100, Lester Caine 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?

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.


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
m...@pooteeweet.org




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.3.0RC4

[Lester Caine]

Johannes Schlüter wrote:

On Sat, 2009-06-20 at 07:49 +0100, Lester Caine 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?


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.


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? :(


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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.3.0RC4

[Johannes Schlüter]

On Sat, 2009-06-20 at 07:49 +0100, Lester Caine 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?

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



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP 5.3.0RC4

[Johannes Schlüter]

Hi,

On Fri, 2009-06-19 at 12:13 +0200, Uwe Schindler wrote:
> /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


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.3.0RC4

[Keisial]

Lester Caine wrote:
> 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?

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.





-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.3.0RC4

[Lester Caine]

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP 5.3.0RC4

[Uwe Schindler]

Hallo,

 

I just wanted to compile PHP 5.3.0RC4 on my Solaris 10 box:

 

panga...@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

theta...@php.net - http://www.php.net

NSAPI SAPI developer

Bremen, Germany

 

 

> -Original Message-

> From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org]

> Sent: Friday, June 19, 2009 10:51 AM

> To: internals@lists.php.net; php-gene...@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 user

Re: [PHP-DEV] PHP 5.3.0RC4

[Pierre Joye]

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 :
>> [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?

-- 
Pierre

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.3.0RC4

[Richard Quadling]

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!"

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.3.0RC4

[Lukas Kahwe Smith]

On 19.06.2009, at 10:50, Lukas Kahwe Smith wrote:


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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP 5.3.0RC4

[Lukas Kahwe Smith]

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



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php