Re: PHP 8 next?

On 25/06/2018 19:54, Zeev Suraski wrote:

On Mon, Jun 25, 2018 at 8:40 PM Chase Peeler <chasepeeler@gmail.com> wrote:

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.

I agree. It was a bad decision on our part to do it in 7.1 - this bit a lot of users.

IIRC, one of the arguments given at the time was "we don't know when 8.0 will be, so we might have to wait for a long time". I never liked that argument, because it sounds like the arrival of a major release is entirely out of our hands, when in fact the opposite is true. My argument then, as now, was that we should plan further ahead when each major release will be, and build up a list of things that will be in it. If anything, I think we should bump the major version number *more* often; if after 3 years we have 10 things like the too_few_args RFC, get them implemented, bump the version number, and move forward. On reflection, I think maybe that phrasing reveals a difference in viewpoint: a lot of people talk about "a major release", which implies there's something big and exciting, rather than just a number. I think of it more like the marks on a ruler: centimetres are not more exciting than millimetres, but they are less frequent, and have some significance.

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.

In an ideal world, there would be no reason *not* to upgrade to the next minor version, because you would know that your code ran on "7.x", so would just install the latest 7.x when it came out. I know reality is never quite that simple, but I think we can get pretty close with a bit of discipline and planning. Regards, -- Rowan Collins [IMSoP]