Zeev, > Secondly, for some reason you appear very opinionated that this will result > in huge breakage, even though we don't yet have any evidence to suggest it'd > be the case, at least not yet.
So I tried to compile the patch to get a real-world idea of the breaks. The first thing, PHP's own phar generator included in the make file fails due to the new restricted hints (based on the patch provided). (I had to rebuild with --disable-phar to get it to build). Let me make that perfectly clear: under these changes you cannot do a default compile of PHP due to BC breaks. Let's take a look at the numbers. I just ran a ./configure --enable-mbstring --disable-phar --enable-debug, and got the following test results: Number of tests : 13653 9008 Tests skipped : 4645 ( 34.0%) -------- Tests warned : 0 ( 0.0%) ( 0.0%) Tests failed : 697 ( 5.1%) ( 7.7%) Expected fail : 32 ( 0.2%) ( 0.4%) Tests passed : 8279 ( 60.6%) ( 91.9%) --------------------------------------------------------------------- Time taken : 954 seconds 7.7% of the internal test suite is extremely significant. That's just short of 700 tests on a reasonably default install. So I recompiled with a bunch more extensions: Number of tests : 13716 10343 Tests failed : 811 ( 5.9%) ( 7.8%) And that's for PHP's suite. What about for the hundreds of millions of lines of code of untested apps out there? I tried running Symfony 2's test suite, but couldn't. Because: $ ../php-src/sapi/cli/php vendor/bin/phpunit Warning: debug_backtrace() expects parameter 1 to be integer, boolean given in Symfony2/vendor/phpunit/phpunit/src/Util/ErrorHandler.php on line 58 Warning: array_shift() expects parameter 1 to be array, null given in Symfony2/vendor/phpunit/phpunit/src/Util/ErrorHandler.php on line 59 Warning: Invalid argument supplied for foreach() in Symfony2/vendor/phpunit/phpunit/src/Util/ErrorHandler.php on line 61 Fatal error: Uncaught strpos() expects parameter 1 to be string, boolean given Symfony2/src/Symfony/Bridge/PhpUnit/DeprecationErrorHandler.php:38 thrown in Symfony2/vendor/phpunit/phpunit/src/Framework/TestSuite.php on line 871 So yeah, to say "major BC issues" is the literal definition of an understatement. > Thirdly, there are major reasons to upgrade to PHP 7, and we'd hopefully > have some major reasons for people to upgrade for 8. There are going to be > substantial carrots next to that breakage stick. Yes, and if we can avoid giving people breaks they can't trivially avoid (via a "compatibility checker" script, like minor syntax changes), then we're just making an artificial barrier for the sake of it. Rather than incentivizing the pain, why not avoid it? > Last, you appear to represent the 'can't be bothered' crowd, which I agree, > is fairly large. But that crowd typically just doesn't upgrade, unless > something or someone twists their arm. They don't upgrade even when there's > no or very little compatibility breakage. That's why 5.3 is still so > popular, and 5.2 isn't rare to find. Let alone 5.4. > > We have a track record that suggests that compatibility breakage slows > adoption down, but it does not kill it as you suggest. > > >> But they will not upgrade their code to PHP 7.1 or 8 then. > > Sooner or later they'd have to, if they want to maintain security. If they > don't - it will not be the first time in history that people are negligent > about their deployment (as the fact there are so many 5.2/5.3 deployments > still out there proves), nothing unique for 7/7.1. Sure there is. We can make it easier for people. We can make their experience with 7 significantly easier than 5.2. We can remove the stigma and the fear associated with upgrading. We've been doing that since 5.4. Smaller, easier and less painful breaks when they do exist. Why not continue that? >> Ok, lets say 4-5 years. Given the lagging adoption of PHP major versions, >> double this situation to 8-10 years in the wild. > > I do believe a 2-3 timeline for 8 (from when 7 is released) is a lot more > likely than 4-5. > The last time we had a major version was, as you know, 11 years ago. We > can't deduce anything about adoption numbers from what we had back then. > We're also on a much more aggressive timeline nowadays, with support for > each version stopping 3 years from when it gets initially released. At > least based on what I'm seeing, adoption cycles appear to be significantly > shorter than they used to be (1-3 years, not 4-5). I fully agree with you here. And if we take that stance, then each major should get "lighter" in terms of what it breaks. To spur people to take the latest at all times, because they know it's stable and a minimal amount of pain. > Of course, much like there are still users of 5.3, we're likely to have > users of 7.0 even in 2025. That's not the point, and shouldn't play a role > in the decision - it'd happen regardless. I think it absolutely plays a role in the decision. We should be making lives easier for our users, not making more work. Especially for the class of user that doesn't stay up to date. > Obviously not, but then, no RFC author that introduced breakage into PHP > ever did, and there has been a lot of that going on, also in 7.0. I'm Hang on a second. All of the breaks that have gone into 7.0 were of two classes up until now: 1. Those that were using deprecated functionality already 2. Those that are 100% statically fixable. You can write a "migration tool" to automatically fix the BC breaks in Nikita's patch. And in the PHP4 constructors patch. And in the reserved types patch. Together they are minor (with the exception of the php4 constructors patch don't affect a lot of production code), but they are also 100% statically fixable. This break is fundamentally different. It's by definition not statically fixable (at least without injecting casts everywhere, which is exactly the point of the patch, no?). So it's going to require a person physically fixing bugs (easier if there's a comprehensive test suite, really not easy if it's manual testing). Thanks Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
