On 12 December 2014 at 23:19, Zeev Suraski <z...@zend.com> wrote: > 3. Last (and probably least) - a 5.7 that breaks compatibility is > inconsistent with our version strategy, that suggests 5.7 should be fully > compatible with 5.6.
Whoa — I'm not talking about breaking compatibility. I'm talking about generating deprecation warnings on things we know are going to break in PHP 7. Travelling backwards a point: > 2. My position about 5.7 that's minimally different from 5.6 and just > 'helps migration', is that it's practically useless. Users won't go through > the headache of hopping through two versions, for some supposed unknown > benefits. PHP 7 breakage is going to be fairly localized to specific > areas - not so much the engine changes which barely breaks anything. So if > 5.7 'breaks' the same areas that 7.0 does (keywords, warnings in the right > places, etc.) - migrating to it would essentially be as painful (or > painless) as migrating to 7.0. In other words, no benefits to doing this > extra step from the point of view of most users. As I said, 5.7 wouldn't break anything, to my mind. The point is to provide a way for users to get a heads up on what things they need to be looking into to either migrate to PHP 7, or have a single code base that runs on both PHP 5 and 7, depending on their needs. The Python experience suggests that both of these cases _need_ to be supported, and well. Why wouldn't we — the people best placed to do so — provide the tooling to do that as part of the runtime? The strawman version of your position seems to be that users are going to just migrate to PHP 7 en masse, and that they'll be happy with their code breaking to tell them what to fix. I'm not sure there's any history in PHP or other languages that suggests that's really what will happen, and I think we're doing our users a disservice if we don't make the path to having a mixed 5/7 code base as easy as possible. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
