Before now each major (5.y+1) release introduced API changes.
We just couldn't introduce literal tables, interned strings, etc without
API changes.
However such API breaks where invisible for user-land and most
extensions, they required a lot of changes in O+, APC, xdebug, etc.
But, in case we freeze the API we just won't be able to add many future
improvements.
Thanks. Dmitry.
On 06/01/2011 03:19 PM, John Crenshaw wrote:
That isn't measurable, so it is a suggestion, not a standard. It also creates
serious problems in userland if APIs change. API changes lead hosts to
literally take years to update to new versions of PHP, for fear of breaking the
sites that host with them. What about:
Userland API compatibility of documented interfaces and behaviors must be kept.
API internals should be backwards compatible wherever possible.
This relaxes the userland restriction just slightly to allow for changes that
break undocumented behaviors, but leaves it basically stable and measurable.
This also leaves the door open for internal changes if they're really needed,
but basically suggests against it.
John Crenshaw
Priacta, Inc.
-----Original Message-----
From: Dmitry Stogov [mailto:dmi...@zend.com]
Sent: Wednesday, June 01, 2011 7:08 AM
To: Pierre Joye
Cc: PHP internals
Subject: Re: [PHP-DEV] Final version, RFC release process
Hi,
In my opinion a restriction "API compatibility must be kept (internals
and userland)" for x.y.z to x.y+1.z is too strict. It just can block
some new features forever.
I would suggest to change "API compatibility must be kept" to "API
backward compatibility must be kept as much as possible".
Thanks. Dmitry.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
