Thanks for taking the time to respond!

1/ Pushing 8.0 as 7.3 + 1 means we're going to rush deprecations into

7.3 which is already in fire-hose mode of last-minute, under-planned

"hey I want this toy" requests. Yes, deprecations are a little bit

more sweaty ice cube in terms of late deprecations being lower risk

that late additions, but it's still turning into a rushed thing during

a season when some folks are off on holiday break. The FF is in

Summer in part because this is a bad time to introduce RFCs.

Note that I did propose that we actually have a thin depredations-only PHP

7.4 (to give credit where credit's due, that's Dmitry's idea). This gives

us ample time without having to rush deprecations into 7.3

2/ In several of theses cases we're talking about something that's not

even fully scoped out yet. Async, for example, "requires a lot more

research". Yes, that research can probably be completed and turned

into an implementation in the 1.5 years we have till the Nov 2019 GA

(whatever version that ends up being), but there are multiple items on

this list which are not (seemingly) fully fleshed out.

I think it's entirely unreaslitic (or remarkably optimistic if you prefer)

to think we'd have this done in under 18 months. There's still tons of

work we'd want to do in the JIT front, the work is entirely ahead of us as

far as async and preloading are concerned - and that's without even

factoring in the amount of time that discussions would take nor the fact

we're likely to still be busy with 7.3 for quite some time. Releasing it

at the end of 2019 effectively means we can squeeze such a huge version in

the same timeline we took for incredibly smaller versions like 7.1, 7.2 or

7.3. I think we're good, but we're not THAT good :) I also don't think

there's anything 'sacred' about releasing at the end of a particular year.

3/ When I read phrases like "open the door for new types of workloads

for PHP (non Web)", and "one of the key reasons Node is gaining

popularity", and " 'bleeding edge' technologies, such as AI and

Machine Learning" I smell a trend of chasing the new hotness and

worrying about factors other than making PHP the best language for the

Web. Growing PHP is great, and evolving it into new areas is also

potentially quite good, but we have history showing what happens

when we come up with something new to chase after that then turns out

to be underwhelming, undermaintained, and underutilized. I've also

seen what a JIT does in terms of additional complexity, it's not

pretty.

First, I'll admit that there's definitely some of that happening. But to

paraphrase my daughters - "I didn't start it!". In other words - people

are very actively looking for ways to run PHP in a Node-like manner, and

with the shift towards micro-services - I don't think it's a fad. I think

we need to go there if we are to stay relevant.

With JIT - it's bit of a mixed bag. After so many efforts went into it and

we managed to get something pretty nice going - it was also a bit of a

solution looking for a problem. That's where the idea of expanding PHP to

other areas came from. And to be perfectly honest - it's not that I

invented this approach either - people have been using PHP for non-Web

workloads since forever. Plus, we're still hopeful that it would show

benefits for the Web world, especially in conjunction with preloading and

the fact it'll enable PHP-based built-in functions (which is another thing

we've wanted for a long time).

With FFI, I think the risks are low and the potential benefits are

substantial. Out of the major ideas, this is probably the one I'm mentally

least attached to - but here too, I see few downsides to doing it.

4/ When the $(%* did we body swap, because it's not quite full

turnabout, but I'm suddenly having flashbacks of "give the language a

rest". :)

People evolve :)

Please don't construe this response as entirely negative. As I said

in other replies, I'm actually quite excited about these new things

and the directions they open up, and it may be that you and Dimitri

have been spending quite a lot of time thinking about them and their

implications to the language going forward. However, like the NG

branch prior to 7.0, most of this appears to lack any sort of plan for

those of us not in your private email threads. Yes, we've discussed

all of them at one point or another, but apart from the JIT, there's

been no obvious signs of work on any of them, which brings me back to

being concerned about 7.3 suddenly being flagged as the last 7.x

release within mere DAYS of its planned feature freeze branch date

without warning.

I'm not taking your comments negatively at all! I do want to point out

that this time around everything we did was done in public as much as we

could - including both JIT and FFI. There hasn't been any meaningful

progress beyond some conference-style brainstorming regarding preloading

and async, virtually all of the work is ahead of us here. If this sounds

like it's messy, it's because it kind of is - because it's a lot more of a

plan-for-a-plan than it is an actual plan. Again, the main goal here is to

gauge the level of willingness of people to say that PHP 8 is going to be

the next feature release of PHP after 7.3, and to allocate a longer

timeline for us to successfully deliver it than the standard yearly cadence

(as was pretty much always the case with major versions). We will of

course discuss each and every one of the ideas separately. Of course, in

theory it's possible we'd shoot down all of the different ideas - but I'm

at least hopeful that wouldn't be the case and we'd have enough material

(both from these ideas and perhaps others) to release a major version

within 2-2.5 years.

Possible alternative. Still aim for Nov 2019 GA of 8.0, but have a

7.4 in parallel with it. This (sort of) happened with 4.4 being

released between 5.0 and 5.1 (I know, not quite the same). This would

give us a couple advantages: 1/ Take our time with these last-minute "deprecate all the things"

RFCs that have suddenly popped up.

2/ Have an escape hatch to delay 8.0 till Nov 2020 if implementations

for the big stuff aren't quite ready for whatever reason rather than

being forced to push them to 9.0

I still think that Dmitry's idea that we have a deprecation-only 7.4

sometime in 2019 makes sense. If we really wanted to we could make it a

deprecation+some extras version, but I'm concerned about fragmenting our

scarce resources. I don't think the sky will fall in case we take 18-24

months between our last 7.x feature release and 8.0. We've had that

between 5.6 and 7.0 and I think it worked pretty well.

Thanks for the feedback!

Zeev