Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94051
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.53 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <b1ffc667-8b74-5be8-9945-f5ebee072045@gmail.com>
References: <6c03dafd-093a-0087-6312-96fede93c5f0@gmail.com>
 <BY2PR0201MB17843F26C4E02181DDDED285BF540@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <1c437efe-7f1d-629f-cfbc-41cbcda38d89@fleshgrinder.com> <CAEZPtU6PonqQcT5sQf1FUd-Vwp-qcZ5r0jzL-Cdn3r3=wpLJDA@mail.gmail.com>
 <CAFMT4NoqmuA-LySitfMJS_2d4re5o75jw7FyqDuHWbZD1S6eLQ@mail.gmail.com> <b1ffc667-8b74-5be8-9945-f5ebee072045@gmail.com>
Date: Thu, 16 Jun 2016 12:11:56 -0600
Message-ID: <CAFMT4NrgMJn8SaNkbQ9H=Jn44A5mKK6iEO8BHu7Uab-kY4XpLQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?
From: levim@php.net (Levi Morrison)

On Thu, Jun 16, 2016 at 10:30 AM, Rowan Collins <rowan.collins@gmail.com> wrote:
> On 16/06/2016 17:24, Levi Morrison wrote:
>>>
>>> I also have to say that to the very short timeline to finalize 7.0
>>> should not be paid by breaking BCs in 7.x. We can have a short
>>> timeline for 8.0 as well. If we need more drastic BC breaks earlier
>>> than expected. If JIT is a goal for 8.0, then let do the BC breaks in
>>> 8.0 and prepare our users using 7.x.
>>
>>
>> I agree with sentiment. However I do not mind certain BC breaks being
>> made in 7.1. For 7.2 and beyond I think we should be significantly
>> more strict on BC breakages.
>
>
> Why? What's special about 7.1? If it was a case of finishing off changes
> that "should have been part of 7.0", I can see some kind of logic, but the
> ones we're actually discussing seem to be more about "preparing for 8.0".

I didn't necessarily mean the currently proposed; I mean more
generally. For instance Nullable Types and the associated
ReflectionType changes both have small BC breaks that I don't mind. In
the case of the former there is a long-standing bug that did have BC
break impact that was fixed. This passed 44 to 1. Stas was the no-vote
and he can clarify his stance but I do not believe he voted no because
of the BC break.

In the case of ReflectionType it's cleaning up an API that was only
introduced in 7.0 to be better integrated with nullable types before
too many people are relying on it.

I think both of these BC breaks are reasonable for a minor that is
immediately following a major.