I don't understand what's wrong with breaking changes. Do they not happen in php major versions anyway? Why not fix the parameter ordering and built in function names whilst you're at it? Seems odd to me.
1. it requires that all your users churn their codebase for something which doesn't directly add value
2. it introduces errors which can remain latent or unfound for a while, especially when you're just changing the parameter ordering of a function in a dynamically typed language
> Do they not happen in php major versions anyway?
PHP has actually been awesome at preserving backwards compatibility.
I wrote a server, when PHP 4 was still the cutting edge, and it still works, now, at 8.1 (although I know that it is being rewritten, in order to leverage things like Laravel).
I set up something for someone in 2003/2004. It was largely PHP4 code that got a bit upgraded to 5.0. We lost touch.
I got a call at end of 2017 saying "this isn't working". Someone else had taken over hosting and been upgrading PHP along the way. There was finally something that broke (some weird dynamic object stuff that was making up for some PHP4 shortfall at the time) and... I did some small patch to get around it but suggested they have someone rebuild, either in PHP 7 or ... any tech from 2017. Just needed to migrate relatively simple database over.
I pointed out that they had basically 13 years of hassle-free system - that's generally a bit outside the norm for that sort of thing, and... that was the recommendation they gave back to their org's board of directors (small non-profit sort of thing).
There are breaking changes - but they tend to be very granular, and typically occur after a few rounds of deprecation. Renaming a bunch of core functions, and doing something radical (like, deleting the `$` prefix requirement) would break every single line of code, in every function, and in every library. It would be Python 3 all over again.
Whereas... imagine if Python 3 rolled out simply as an optional "mode of operation" on top of Python 2. If you opt-in on this particular file, the syntax requirements are different. Obviously that would prevent some deeper changes, but it would help modernize the language without as much of a radical break.
> Whereas... imagine if Python 3 rolled out simply as an optional "mode of operation" on top of Python 2.
It's easy to imagine: Python 3 would not have existed. At all.
Python 3 changed fundamental language semantics in ways which went way beyond syntax, that's why the core team shoveled so many changes in: they were breaking the language in a way which didn't brook mere syntactic opt-ins, this meant additional changes were minor issues easily handled compared to the fundamental difficulty of overhauling the language's entire string model and significant parts of the object model.
> If you opt-in on this particular file, the syntax requirements are different.
Sometimes it's fine, sometimes it's not. And PHP has VERY FEW breaking changes in general.
Think about something like WordPress, it powers so much of the internet, they're not going to be doing massive rewrites so that PHP can fix some legacy issues.
