> I assume you're referring to what the upgrade guide refers to as "Backward Incompatible Changes". If so reading through the list I can't see a single one on there that has a major impact, in fact I'd wager that 99% of all 8.3 instances will have no issue upgrading to 8.4 as they are all very superficial changes to some very legacy areas of the language.
They changed error handling. That is a major impact. If things start throwing errors when they previously didn't it results in your app breaking because how you were handling errors is no longer applicable. Now you have third-party libraries, etc all breaking because the PHP core team can't be bothered to follow industry standards. And yes, SemVar is, at this point, the industry standard to the point people use 8.* in their composer require because they expect SemVar.
And changing error handling in very legacy areas of the code is the worst especially when there isn't even an RFC to say that they would be doing it. The fact it's legacy means people don't expect it to change.
> I'm also not seeing 200 on there, though you said "200 lines" are you talking about the length of the article, if so thats not really a helpful metric.
It's useful in giving an impression of the number of changes. Especially, when given an example of another release to see how they're increasing. And it's extremely useful when comparing to other languages where the breaking changes section either doesn't exist or it's extremely small. 200+ lines even with formatting and some lines taking two ends up with over 100 breaking changes.
I get it, you like PHP and you're protective over your tooling. I use PHP heavily, in fact, I'm building my business on top of it. But that does not remove my ability to look at how everything is compared to other languages and see there is a major problem. On Ubuntu, it has packages for each minor release whereas in Python it's just python3-*. Why? Because PHP's reputation for adding breaking changes whenever (despite the claim that they're really good at it) has been there for so long that even Linux distros know that people need to deal with that pain.
The problem with me being mainly a PHP developer is, I know all the problems. You can't BS me like you can devs who don't work with it so much.
They changed error handling. That is a major impact. If things start throwing errors when they previously didn't it results in your app breaking because how you were handling errors is no longer applicable. Now you have third-party libraries, etc all breaking because the PHP core team can't be bothered to follow industry standards. And yes, SemVar is, at this point, the industry standard to the point people use 8.* in their composer require because they expect SemVar.
And changing error handling in very legacy areas of the code is the worst especially when there isn't even an RFC to say that they would be doing it. The fact it's legacy means people don't expect it to change.
> I'm also not seeing 200 on there, though you said "200 lines" are you talking about the length of the article, if so thats not really a helpful metric.
It's useful in giving an impression of the number of changes. Especially, when given an example of another release to see how they're increasing. And it's extremely useful when comparing to other languages where the breaking changes section either doesn't exist or it's extremely small. 200+ lines even with formatting and some lines taking two ends up with over 100 breaking changes.
I get it, you like PHP and you're protective over your tooling. I use PHP heavily, in fact, I'm building my business on top of it. But that does not remove my ability to look at how everything is compared to other languages and see there is a major problem. On Ubuntu, it has packages for each minor release whereas in Python it's just python3-*. Why? Because PHP's reputation for adding breaking changes whenever (despite the claim that they're really good at it) has been there for so long that even Linux distros know that people need to deal with that pain.
The problem with me being mainly a PHP developer is, I know all the problems. You can't BS me like you can devs who don't work with it so much.