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:
[email protected]]
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.