Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94015
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.171 as permitted sender)
To: internals@lists.php.net
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>
 <55d87b00-ebcd-6132-ea29-1978236930e7@seld.be>
Message-ID: <1c89124f-03fc-65dd-f6ce-dbf23e888ce6@gmail.com>
Date: Wed, 15 Jun 2016 17:10:36 +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: <55d87b00-ebcd-6132-ea29-1978236930e7@seld.be>
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 15/06/2016 12:38, Jordi Boggiano wrote:
> On 15/06/2016 11:41, Pierre Joye wrote:
>> I also understand the needs to change, update, optimize or clean our
>> edge cases to open the path to JIT and the likes. However I would be
>> very careful about that, and Dmitry and the team are very careful. 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.
>
> +1 to that, it would be much better to introduce BC (strong/er) warnings
> in 7.1/7.2 and then if needed branch off 8.0 already so that JIT work
> can happen there with the BC warnings (and related features) removed.
> 8.0 could then come a year or two after 7.1 depending on how the JIT
> work progresses.

Dmitry, Stas, do you think something like this could work? Could we have 
a "php.next" preview branch with lots of performance work going on, 
especially if a lot of it is focused around opcache anyway?

- You could still raise RFCs for expected breaking changes, to make sure 
you have approval for a language change before investing time depending 
on it, but set their target as 8.0.
- Users would know what to expect from each release, and have plenty of 
notice to make their code "php8-ready".
- Even if we're not ready to turn on JIT, an accumulation of 
improvements would give users a more visible incentive to handle any 
compatibility problems.
- Grander plans that don't happen to be ready at the same time can 
always go into 9.0 instead.


> This would keep the "BC promise" intact instead of
> going back to cowboy php days.

This. A hundred times this. Please don't let's make it harder to go from 
7.0 to 7.1 than it was from 5.6 to 7.0.


Regards,
-- 
Rowan Collins
[IMSoP]