On Wed, 1 May 2019 at 00:56, Stanislav Malyshev <smalys...@gmail.com> wrote: > > 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.
It is a BC break nevertheless no matter how much time it takes to change the code. The level of the impact cannot be measured like this. Every app will have different things to fix. So saying that this particular change will break the internet is not realistic without any numbers. If PHP is on a course to fix the BC break strategy then good (for example, BC breaks allowed in major releases, minor releases including only new features etc). Upgrading PHP version would be then a breeze probably but very complex to maintain the code in the repo (at least according to the release cycles of 5+ years to get to a major version). However, I'm not sure I'm seeing such direction or anyone expressing it to do this at least according to many here and even this discussion. Because, from what I think here more is that we're discussing how to keep the short tags forever and how to remove them as soon as possible. There is a difference in what people want here. And majority of those not in favour of the removal in PHP 8, want them to have forever and basically want to change the issue of removing the tags in the first place. I haven't seen any step forward from this point yet and what kind of a different removal strategy (compared to Nikita's suggestion) would work. > > 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. I haven't seen code with short tags for such a long time now that this is for me a problem on a scale of a fly. Because we've simply upgraded all very very long time ago or in other words even never thought of writing something in these tags anymore. Well, obviously this might be for someone else a problem on a scale of an elephant, that I don't know and probably won't understand fully. But, also at least now this discussion and also RFC brought this thing out - short open tags shouldn't be used anymore in any case. :) Because obviously a very large number of people would like to have more clear definition of what is opening PHP tag. -- Peter Kokot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
