[PHP-DEV] Re: svn: /php/php-src/trunk/ UPGRADING.INTERNALS ext/date/php_date.c ext/date/php_date.h

2010-09-27 Thread Michael Wallner
What's the idea behind breaking compatibility of backwards compatible APIs? ;) Cheers, Mike On 09/27/2010 03:19 AM, Kalle Sommer Nielsen wrote: kalleMon, 27 Sep 2010 01:19:57 + Revision: http://svn.php.net/viewvc?view=revision&revision=303773 Log: Remov

Re: [PHP-DEV] Re: svn: /php/php-src/trunk/ UPGRADING.INTERNALS ext/date/php_date.c ext/date/php_date.h

2010-09-27 Thread Pierre Joye
hi, On Mon, Sep 27, 2010 at 4:21 PM, Michael Wallner wrote: > What's the idea behind breaking compatibility of backwards compatible APIs? > ;) That's why php-next is not php 5.3.x but something either 6 or 5.4. About this change, it is usually a good thing as tsrmls_fetch is horribly slow. Che

Re: [PHP-DEV] Re: svn: /php/php-src/trunk/ UPGRADING.INTERNALS ext/date/php_date.c ext/date/php_date.h

2010-09-27 Thread Johannes Schlüter
On Mon, 2010-09-27 at 16:27 +0200, Pierre Joye wrote: > hi, > > On Mon, Sep 27, 2010 at 4:21 PM, Michael Wallner wrote: > > What's the idea behind breaking compatibility of backwards compatible APIs? > > ;) > > That's why php-next is not php 5.3.x but something either 6 or 5.4. > > About this c

Re: [PHP-DEV] Re: svn: /php/php-src/trunk/ UPGRADING.INTERNALS ext/date/php_date.c ext/date/php_date.h

2010-09-27 Thread Kalle Sommer Nielsen
Hi 2010/9/27 Johannes Schlüter : > I think Mike's point was that these functions, according to the comment, > only exist for BC reasons. So they should either keep BC or be dropped. > The only usage php_idate() exists for is the idate() function, i greped pecl and tried to use OpenGrok, but it wa