Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93934
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.53 as permitted sender)
To: Joe Watkins <pthreads@pthreads.org>, Anatol Belski <ab@php.net>
References: <6c03dafd-093a-0087-6312-96fede93c5f0@gmail.com>
 <CAH-PCH5e6_aTCQEPd8=B0sFwsWsDfaG+2Fsp4i93t3qmxgmQQQ@mail.gmail.com>
 <020a01d1c501$3d3d9420$b7b8bc60$@php.net>
 <CAL=_i_mibDngeQ3-ejhxCUCQmWSYivdgrvoFFZyKAJ6H63Twmg@mail.gmail.com>
Cc: Ferenc Kovacs <tyra3l@gmail.com>, Joe Watkins <krakjoe@php.net>,
 Davey Shafik <davey@php.net>, PHP Internals <internals@lists.php.net>
Message-ID: <c780790b-fe68-820a-8a5b-0e69fdce5d5e@gmail.com>
Date: Mon, 13 Jun 2016 13:28:49 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <CAL=_i_mibDngeQ3-ejhxCUCQmWSYivdgrvoFFZyKAJ6H63Twmg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy
 enforceable?
From: rowan.collins@gmail.com (Rowan Collins)

On 13/06/2016 10:35, Joe Watkins wrote:
>     Backward compatibility is important. Also important is the long term
> goals for PHP, or at least for this major version of PHP: The goal is to
> make Zend so efficient that generating machine code from user code
> becomes a deployable solution.

OK, that's an interesting bit of background, which might explain why 
Dmitry seemed in a hurry to get this in place. I was aware of the 
discussion of performance, but not the background "long-term goal". Is 
there a roadmap somewhere that describes this, or any background 
discussion of doing this within the 7.x series, rather than planning for 
8.0?


>     I can be wrong, might be ... it doesn't really matter, the majority
> has spoken. It is only my concern that the change is documented properly.

This is my main concern, also. The RFC is very brief, and the discussion 
period was artificially shortened, and I think the implications to the 
BC policy make this RFC more important than Dmitry assumed.

Having a documented reason why a BC break was accepted in this case will 
help to set expectations in the future. Ideally, this could lead to a 
revised policy with BC guidelines that actually match the current 
reality of the project, which the existing RFC does not seem to do.

Regards,
-- 
Rowan Collins
[IMSoP]