I've argued before that there should be a roadmap and a cycle for major

releases, and if not, then some agreement on what triggers one, but we've

so far not managed to agree either. I do believe a road map and a cycle is a good idea. I'm hearing some

complaints from on the ground that releases are currently too frequent,

making it difficult for larger organisations to keep up when they have

to retest all their own apps/libraries/plugins with the new versions. A fixed cycle and schedule could help plan for change. --

Mark Baker |. \ -3

|J/ PHP |

|| | __ |

|| |m| |m| I LOVE PHP -- I'd like to put in my two cents as someone in userland that isn't really

involved with the development lifecycle of PHP. I'm aware that my opinions

might not be shared by others, so I'm not claiming to speak for anyone else.

I've always viewed major releases as "This has MAJOR changes to the

backbone of PHP" - Old code is more likely to break during a major update,

but, doesn't have too. Minor releases, on the other hand, are more about

fixing the bigger bugs and introducing some new functionality, but nothing

ground-breaking. While still possible, the chances of old code breaking

should be pretty small. Changing that third number is just about security

and bug fixes.

Let me expand on two of those points:

1.) Old code breaks during minor updates. We upgraded to 7.0 AFTER 7.1 was

released, because we had already made major updates to upgrade to 7.0, and

7.1 introduced a few things that would have broken our code - we didn't

have time to fix those by that point. "Throw on passing too few function

arguments" would actually break more stuff in our legacy code than all of

the 7.0 changes combined.

2.) JIT, FFI, and Async are things I'd consider "major changes to the

backbone of PHP" just like the overhauled engine in PHP 7.

Finally, I personally see the idea of a deprecation only release to be kind

of silly. I don't work for a software company. It's tough enough for me to

make a case for upgrading using the "increase performance" and "new

features" argument. There is no way I'd get the go-ahead to do an upgrade

that would just make additional features deprecated. It would be a better

use of my time to look for and fix the deprecated features as part of the

8.0 upgrade prep, than to upgrade to 7.4. Maybe look at at backporting some

of the new 8.0 features that aren't really dependent on the major things

like JIT, async, etc., as part of the 7.4 release.

--

-- Chase

[email protected]