RE: [PHP-DEV] PHP 8 next?
| From: | Zeev Suraski | Date: | Sun, 24 Jun 2018 20:09:09 +0000 |
| Subject: | RE: [PHP-DEV] PHP 8 next? | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-102398@lists.php.net to get a copy of this message | ||
> -----Original Message-----
> From: Levi Morrison [mailto:levim@php.net]
> Sent: Sunday, June 24, 2018 5:31 PM
> To: Zeev Suraski <zeev@zend.com>
> Cc: internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] PHP 8 next?
>
> > The trigger for a major release has always been very substantial
> improvements/changes to the language, which I believe JIT, FFI and potentially
> async squarely fit into (and I'll explain why I think that separately later this
> week). This is true for PHP 3, 4, 5 and 7 (even though 3 and 5 did introduce
> inherent compatibility breakages as a part of its new functionality).
>
> My position stands: I *strongly* object. If we rush to PHP 8 then it will be at
> least 4-5 more years before we have another chance for breakages in PHP 9. We
> can add features yearly.
Fair enough, your position is obviously entirely up to you - I just wanted to point out that having
pushing a major version was never about breaking things - it was about delivering major new
capabilities or performance to users - with the ability to break things as a side effect. I
don't think I've ever seen nor delivered a PHP 7 presentation that included statements
like "I can't wait to show you all the different things we broke in this new major
version!!!" - this isn't what major versions are about.
I should also add that my position also stands - there's nothing that spectacular about
breaking things, and for me at least, the celebration of being able to break things and the yearn to
break more things before 4-5 years pass by is awkward. If we could bring major value with the users
being able to just upgrade without an intense code audit/refactoring cycles, it's a feature -
not a bug as far as I'm concerned.
That said - it's OK that we break things if the value of breaking them far outweighs the cost
of fixing the consequences of the breakage - and by that I mean a more prolonged upgrade cycle and a
certain degree of user angst.
Zeev