Re: Is the "No BC Breaks in Minor Releases" policy enforceable?

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]