Re: [RFC] PHP 5.7

On Tue, 16 Dec 2014, Ferenc Kovacs wrote: > > > - Rolling out a 5.7 with Warnings-of-any-kind + some little-or-not > > > new features cancels point number one > > > > > > What else ? > > > > Do nothing is still (IMHO) the most sensible option IMHO. We're not > > seeing major compatibility breakages in 7.0 (at least not at this > > time), to the level that upgrading through some middle version is > > really all that necessary. > > we don't have much or really big ones(yet), we have a couple of nasty > ones (eg. doesn't blow up, but behaves differently, check the mails > from Derick complaining about those). Those should never have made it into PHP 7 at all. It's like a big "fuck you" to users. > and there are a couple ones upcoming/likely to make it through: > > https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 I think we should bump up the granularity of the voting options there. As some I think are ok, for example: - dl on fpm-fcgi (since PHP 5.3) But others are not: - CN_match and SNI_server_name stream context option (since PHP 5.6; use peer_name instead) [TODO] > > The one option that could be relevant to these scenarios is a > > separate analysis tool, but it's much more difficult to pull off, > > and I don't think the level of breakage (as it appears right now) > > justifies the effort. > > fortunately we already have a couple of those for some of the nasty changes > like https://gist.github.com/nikic/ffd019ef78b72934c7cc for > finding code > which would be affected by the behavior change of > https://wiki.php.net/rfc/uniform_variable_syntax > I do think that while those kind of extra steps are not mandatory per se, > but they help a lot when convincing people to jump the ship and upgrade. I would go as far as making it mandatory if you change bahaviour of existing syntax that can't be detected through a simple "php -l". cheers, Derick