Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93940
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)
MIME-Version: 1.0
In-Reply-To: <CAL=_i_nxLUz_1xiS3EAr=v8PcSdoSapkWe46LEv4snFH__dbuA@mail.gmail.com>
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>
Date: Mon, 13 Jun 2016 17:23:06 +0200
Message-ID: <CAH-PCH4akZWhdY9V-BdHbLE1xZ_VrmcsOwJOjDD86jCNp8Ggfg@mail.gmail.com>
To: Joe Watkins <pthreads@pthreads.org>
Cc: Rowan Collins <rowan.collins@gmail.com>, Anatol Belski <ab@php.net>, Joe Watkins <krakjoe@php.net>, 
	Davey Shafik <davey@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1141f04224995d05352a773f
Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a1141f04224995d05352a773f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 13, 2016 at 4:32 PM, Joe Watkins <pthreads@pthreads.org> 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 :)
>
> 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 f=
or
> NG, which is very useful research, but it sucks so hard that we can't
> deploy it.
>
> The reason for this is that, in part, generated code doesn't look so much
> different to code executed by the VM, though details differ considerably;
> It needs to do at least the same job, it may need to do more (because of
> guarding and other boring things).
>
> Without knowing anything about generating instructions anyone can tell
> that a complicated Zend, with all kinds of edge cases and inconsistencies
> (specifically regarding ZE) is going to necessitate the generation of
> complicated code, to accommodate those edge cases and inconsistencies.
>
> A lot of effort is being put in to finding and resolving inconsistencies
> in the engine such as this, a lot of effort has been expended and will be
> expended on 7 in the pursuit of efficiency. A lot of this is of no
> consequence to BC.
>
> 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.
>
> The kinds of changes that must be delayed until 8.0 are surely going to b=
e
> proposed, and we will surely delay them by consensus.
>
> > This is my main concern, also
>
> I will update the RFC, if Dmitry doesn't, when voting is closed.
>
> I will ensure the change is properly documented in the manual also.
>
> > 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 other=
s
> do.
>
> I know it's very strange to hear someone talking about "goals" ...
>
> We can waste a bunch of time trying to define them, voting on them, and s=
o
> on ... or, we can look at what is going on, and what has gone on, and com=
e
> to sensible conclusions.
>
> Cheers
> Joe
>
>
>
On the other hand lack of release process and constant BC breaks also
hindered the adoption of past PHP versions.
With 7.0 we were in a good spot as we were able to package the BC breaks
with major performance improvements which makes it attractive for people to
upgrade(and still, with a successful 7.0 release we voted to delay the eol
date for 5.6).
While I don't want to impede progress we have to be careful about BC
breaks, and especially when from the outside it can be seen as some people
are above the rules/processes while others get gated by it.
From the user POV I really liked what we were doing in the past: mark stuff
first with E_DEPRECATED and then remove the feature later on.
I think that our main problem is that we don't have a roadmap for major
versions and historically our major release cycle was pretty slow (4.0.0:
2000, 5.0.0: 2004, 5.3 was basically a major version in 2009 and 7.0.0:
2015 dec), so now that a major just shipped people will try to squeeze in
BC breaks regardless of our release process (and yes, it doesn't not help
that the releaseprocess rfc was lacking clear definitions on some terms).
As I mentioned before I don't wanna impede progress so not trying to block
this specific rfc seeing how well the votes went, but I think it would be
useful for the future governance if we could:
1, update/expand our releaseprocess rfc so that it reflects the
actual/desired process and can spare us from the bureaucracy and word
twisting to suite one's current position.
2, figure out how can we do BC breaks in a more timely manner (either via
changing the releaseprocess, reclassifying what BC break means or having
more frequent major versions).

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a1141f04224995d05352a773f--