Hi! > Worth noting another inconsistency here that we've missed. PHP 7.4 has > introduced many BC breaks actually already. Without this level of > problems:
Exactly, without. There's a difference between removing an unmaintained extension which is barely used and setting people up for displaying their sources if they use slightly outdated libraries. And there's a difference between explicitly making a decision and not even bothering to discuss this mammoth of a BC break until the vote is finished. So to me it's more like "elephant in the room" scenario - we've got a process failure here. We are on the course to correct it, but it's a failure nevertheless. > The deprecation in PHP 7.4 (or even if there wouldn't be any > deprecation here at all) and removal of some short tags in PHP 8 is > the least of users problems I think. You mean wddx removal is much bigger problem for users than the potential for their code to be sent out instead of executed? If so, we must be living in very different words, because for me the former is a blip on the margin of the radar and the latter is a "world on fire, do not upgrade under any circumstances" scenario. I could easily ignore the former and I wouldn't dare to upgrade any production for the latter without long process of verification that would 100% ensure there's no bad tags hiding in any code, any dependency, any library, etc. Maybe it's what the RFC authors want, but it's certainly a giant difference in BC impact. > Without these kind of "hacks" PHP wouldn't even move forward anymore. > Contributing to it would be in most cases only maintenance, fixing > bugs and compatibility with platforms out there. So nothing exciting There's a lot to do in PHP without breaking things. How much time you've got? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
