Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52686
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.199.177.89 as permitted sender)
Message-ID: <4DE66D07.2060105@zend.com>
Date: Wed, 1 Jun 2011 20:47:03 +0400
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10
MIME-Version: 1.0
To: John Crenshaw <johncrenshaw@priacta.com>
CC: PHP internals <internals@lists.php.net>
References: <BANLkTim2Tbw+9egfrmrYfeZfNNwYWcg4dg@mail.gmail.com> <4DE61D77.7040506@zend.com> <A633CF2D7C7BED41B41F1E64F25507B80602209F02@MAILR001.mail.lan>
In-Reply-To: <A633CF2D7C7BED41B41F1E64F25507B80602209F02@MAILR001.mail.lan>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Final version, RFC release process
From: dmitry@zend.com (Dmitry Stogov)

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:dmitry@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.
>