On Monday, June 25, 2018 11:16:31 AM CDT Sara Golemon wrote: > > 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. > > Fair point. I've certainly had discussions with Liz Smith and even > been on Zend sponsored podcasts discussing ways we might "appify" PHP. > But, and perhaps I'm just a bit more skeptical of the microservices > train, I think we should be judicious in our pursuit of the new > hotness. That's all. Most of my response was centered on what felt > like a rush. Factoring in that entire paragraph about having a thin > 7.4 release with a subsequent 8.0 GA alleviates my concerns a great > deal.
When we speak of "typical web loads" not getting much benefit here, are we really talking about CGI-style "reboot every request" type loads rather than "IO-bound work"? Because it's been observed many times in the past that one of the most expensive parts of a modern PHP app is simply booting up, initializing all of the services, wiring everything together... and then throwing it away 100 ms later. If a JIT would make it more viable to pre- start a web process (there are various all-user-space implementations in the wild already) so that an incoming request already had a fully booted system with container initialized and stuff, that could have a huge impact on web loads, even without going all-in on Node-style async. (I am, of course, possibly talking out of my butt here. Please advise if so.) > > 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. > > I'm not against some features for 7.4. I'd even say Niki's typed > properties (which isn't a minor change) can slot in there happily > enough. But we can dig in deeper over time on that. Maybe he gets it > into 7.3? ¯\_(ツ)_/¯ > > -Sara Question from the peanut gallery: why would 7.4 need to be a deprecation- mostly release? Is the concern that it would make merging to the engine changes in 8.0 harder? Something else? I guess I'm missing why a 7.4 that adds warnings about "stop doing this now so your code works in 8" would conflict with a 7.4 that also adds whatever routine functionality or improvements get developed in the meantime. (Typed properties or otherwise.) Historical note: If we view PHP 5.3 as PHP 6 (which it was in any meaningful sense), then PHP's had a remarkably consistent ~5 year run for each major version for quite some time now. That would put November 2020 as the natural, expected release date for 8.0, which especially if it's signaled now would give everyone ample time to prepare and expect it right on schedule. Also, while uptake of new PHP versions is still way slower than the release of new PHP versions, at least based on the Composer data that Jordi releases it's getting steadily better over time. The reasons for that are likely complex but we're a long long way from the days when the GoPHP5 project was needed. :-) (And good riddance to those days.) --Larry Garfield
signature.asc
Description: This is a digitally signed message part.
