On 25/06/2018 19:54, Zeev Suraski wrote:
On Mon, Jun 25, 2018 at 8:40 PM Chase Peeler <chasepee...@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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
