> -----Original Message----- > From: Levi Morrison [mailto:le...@php.net] > Sent: Sunday, June 24, 2018 5:31 PM > To: Zeev Suraski <z...@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
