Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93948
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)
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>
 <c780790b-fe68-820a-8a5b-0e69fdce5d5e@gmail.com>
 <CAL=_i_nxLUz_1xiS3EAr=v8PcSdoSapkWe46LEv4snFH__dbuA@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Message-ID: <49e9733f-9fc4-b9d8-6a04-4c26e8b54fc3@gmail.com>
Date: Tue, 14 Jun 2016 10:46:28 +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_nxLUz_1xiS3EAr=v8PcSdoSapkWe46LEv4snFH__dbuA@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 15:32, Joe Watkins wrote:
> Afternoon internals,
>
>> 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?
>
> We have no such sensible thing as a plan :)


Heh, fair enough. :)

I think a roadmap for PHP in general would be no bad thing, actually - 
somewhere to plot out longer term goals, and a way to make future 
releases more visible. At the moment, it's quite unusual to that might 
be less true if there were a draft list of features for 7.2, and indeed 8.0.



> The reason for the existence of PHP 7 (ng) is efficiency of the kind I
> described, this is surely well understood by everyone.
>
> What may not be well understood is that the job is nothing like
> complete. Vigilant observers will have noticed that Dmitry does indeed
> have a JIT for NG, which is very useful research, but it sucks so hard
> that we can't deploy it.
> [...]
> You can count the number of people putting in the majority of this
> effort on your fingers ... erecting a road block in front of them in the
> name of unobtainable BC is harmful to the apparent goals of the project
> at this time.

This effort is absolutely appreciated, and I definitely don't want to 
erect road blocks just for the sake of procedure.

That said, we do need to ensure we are on the same road, and that is 
largely about communication. The last thing any of us wants is for 
somebody to spend weeks working on an engine optimisation, then have it 
conflict with what other people are trying to do at the language level.

This includes resisting the temptation to skip or fast-track processes, 
and being clear in why a change is needed, and why it's needed now. The 
more visibility there is of the big picture, the easier it becomes to 
explain the details (e.g. "this change is necessary to progress the 
project I was telling you about last month").

One idea that occurred to me was some form of regular update of what is 
going on in engine development. Just a mail to the list a couple of 
times a month saying "we have an interesting prototype of X; A is 
working on a major refactoring of Y; B has managed to make Z 20% faster".



>> Ideally, this could lead to a revised policy
>
> I think our policy has always been to consider each proposal on a
> case-by-case basis. That's all I have done, and all I am suggesting
> others do.

It may be the policy that people have been following, but it's not the 
policy that's written down. A "revised policy" doesn't have to mean 
changing what we do; it could mean describing what is currently 
happening in a new RFC, so that our documentation matches reality.


Regards,
-- 
Rowan Collins
[IMSoP]