Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94033
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.213.53 cause and error)
MIME-Version: 1.0
In-Reply-To: <1c89124f-03fc-65dd-f6ce-dbf23e888ce6@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>
	<55d87b00-ebcd-6132-ea29-1978236930e7@seld.be>
	<1c89124f-03fc-65dd-f6ce-dbf23e888ce6@gmail.com>
Date: Thu, 16 Jun 2016 05:40:59 +0100
Message-ID: <CAL=_i_=Pbz7kTrffwBeerwyM=DfVPtmtUBST_SUdzOs_E6ivvw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114dbf0638dffd05355dd8ac
Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?
From: pthreads@pthreads.org (Joe Watkins)

--001a114dbf0638dffd05355dd8ac
Content-Type: text/plain; charset=UTF-8

Morning,

   > This would keep the "BC promise" intact instead of going back to
cowboy php days.

   > 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.

   Can we reduce hyperbole to nil, please.

   Before work starts on PHP 8, we need to have something worth branching,
just as we needed for 7, and 6.

   There is no sense in which the too_few_args vote was unfair, biased, or
anything comparable to "the old days" (it wasn't committed without public
consultation).

   The majority have decided that the *extremely minor* BC break is worth
the tradeoff.

Cheers
Joe


On Wed, Jun 15, 2016 at 5:10 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> 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]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a114dbf0638dffd05355dd8ac--