My complaint was adding lots of breaking changes to minor version upgrades. The fact, that historically they didn’t do breaking changes in major version upgrades does not excuse going against industry standards.
There are literally companies stuck on PHP 7 because going to 8 is too painful. And honestly with my decade of experience your claim that going from 4 to 8 isn’t that painful sounds like nonsense and something you haven’t done. And the claim that php 4 code will work on php 8 is 100% nonsense. The syntax for how classes were defined in 4 is not supported in 8.
I’ve upgraded the code to the major versions of other languages without hassle. But they generally had fewer breaking changes in their major versions when I upgraded to Vue3 which was super painless.
And can you point to a minor upgrade where Go changed the syntax to the point the old one no longer works? With Go normally it's the tooling that changes. I can't remember the syntax changing on me. Especially since they have a Compatability Promise[1] it seems weird.
> There are literally companies stuck on PHP 7 because going to 8 is too painful.
Usually due to frameworks. Those tend to do play fast and loose with language constructs so small changes can make them not work anymore. And as those same framework will also break a lot more things between version, you cannot easily upgrade them, so you cannot upgrade your php version.
Currently maintaining an internal symfony 1 website so I know the pain. At least the documentation of old symfony is still available unlike many more modern frameworks.
Our best engineer spent 2 weeks full time updating our codebase from 7 to 8 using rector (the project was already running PHP 7 but still had a lot of deprecated code from the PHP 5 era which didn't work on PHP 8). That would be eternity without Rector.
I've previously used that to do something. Fell flat on its face. But the fact they literally had to create a tool to solve this problem confirms my point.
You are right, going from 4 to 8 is a huge challenge.
Minor point: classes are using the same syntax but you are right they typically won't work because the constructor have changed, in PHP4 it was a function named the same as the class, in PHP5 and on it's __construct, the PHP4 version was deprecated in PHP 7 and removed in PHP 8.0.
create_function is just gone. So is each(). Oh and HTTP_RAW_POST_DATA. The list is long.
If you have used == and in PHP4 we did that, come on, don't be holier than holy and claim you only used === in PHP4 then PHP8 will have some surprises for you.
In my experience rector became usable last year-ish, if you tried before, give it another whirl.
There are literally companies stuck on PHP 7 because going to 8 is too painful. And honestly with my decade of experience your claim that going from 4 to 8 isn’t that painful sounds like nonsense and something you haven’t done. And the claim that php 4 code will work on php 8 is 100% nonsense. The syntax for how classes were defined in 4 is not supported in 8.
I’ve upgraded the code to the major versions of other languages without hassle. But they generally had fewer breaking changes in their major versions when I upgraded to Vue3 which was super painless.
And can you point to a minor upgrade where Go changed the syntax to the point the old one no longer works? With Go normally it's the tooling that changes. I can't remember the syntax changing on me. Especially since they have a Compatability Promise[1] it seems weird.
[1] https://go.dev/doc/go1compat