On Tue, Jul 10, 2018 at 10:36 AM Nikita Popov <nikita....@gmail.com> wrote:
> On Tue, Jul 10, 2018 at 8:16 AM, Zeev Suraski <vsura...@gmail.com> wrote: > >> >> >> > -----Original Message----- >> > From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara >> > Golemon >> > Sent: Monday, July 9, 2018 5:41 PM >> > To: Christoph M. Becker <cmbecke...@gmx.de> >> > Cc: Nikita Popov <nikita....@gmail.com>; Kalle Sommer Nielsen >> > <ka...@php.net>; Internals <internals@lists.php.net> >> > Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3 >> > >> > On Sun, Jul 8, 2018 at 5:41 PM, Christoph M. Becker <cmbecke...@gmx.de> >> > wrote: >> > > Sorry, that there has not been any decision yet. However, Sara >> > > suggested that this decision is not solely up to the RMs[1], and I >> > > wouldn't know how to decide it then[2], since there has been at least >> > > one objection[3]. >> > > >> > To clarify, it's ultimately an RM decision, but it should be guided by >> the larger >> > internals@ group. >> > >> > The way I read Zeev's objection is that it's primarily against TP, and >> not against >> > pushing out the FF per se. I would recommend (in a non-RM, unofficial >> capacity) >> > pushing out the FF (not necessarily GA, but we can make that decision >> later). If >> > these last minute things pass, they go in. If they fail, then all >> we've done is >> > burned a month. >> >> It's a bit of both really. >> >> I hope that with all things considered (the little time we have left, the >> little concrete discussion that happened so far as a result, the >> inconsistency of allowing such a vote to push out feature freeze, the scope >> of this feature being a lot more suitable for a major release, and our >> inability to fix/improve other related elements at the same time) - Nikita >> will propose this for 8.0 instead of 7.x. >> > > To make sure there are no unreasonable expectations involved in this > decision: If this feature will not go into PHP 7.3, then it will in all > likelihood go into PHP 7.4 instead. I think I can safely say not just on > behalf on Bob and myself, but also on behalf of the wider PHP community, > that we are not willing to sit on this feature for 2.5~3 years until a > hypothetical PHP 8, even though it is essentially ready *now*. Of course, > this is not my decision to make, but as Sara put it, that's the writing on > the wall. By deciding not to include this in PHP 7.3, we are essentially > making an implicit decision that PHP 7.4 is going to be a relatively > ordinary feature release rather than a deprecation-only one. (Which is fine > by me really, I don't like the idea of a release that's all stick and no > carrot.) > Thanks for choosing not to push it for 7.3. At the same time - I think the push for inclusion in 7.4 will be regrettable. Other parts of what I'd like to see in PHP 8 is, in fact, ready and can theoretically become a part of PHP 7.4 (even JIT, potentially). The reason we're doing it is twofold - one, that's the expectation around major releases - that they will come with major new features; And two, perhaps more importantly - is that big features sweeten the deal associated with migrating to a new major versions, with the incompatibilities introduced and the code audits required. I obviously know it's extremely difficult to sit on new working code for prolonged periods of time - but it can very much be the right thing to do. We did exactly that with the phpng codebase (which introduced virtually zero incompatibilities, and could in theory be included in PHP 5.7), and we're likely going to do that again with JIT and FFI. Either way, I'll state my case when the discussion becomes relevant again. In the PHP 8 RFC that I'm hoping to begin drafting in the near future, my goal is to present 7.4 as a 'deprecation mostly' version, which while it won't be forbidden to include new functionality in it, it will be discouraged (with probably no 'teeth' to this discouragement, i.e. a successful vote would still land a new feature into 7.4). Zeev
