> That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes.
this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code?
I just don't understand why people accept this from their tools. Imagine if Google would just randomly change their APIs every couple of months and then stop supporting the old ones. Nobody would use their stuff. But somehow the PHP community thinks this is perfectly normal.
Because, suprisingly, Noone is forcing you to update immediately!
Hell, there's still a lot of 5.x deployments out there that work just fine. I even manage one or two (both of them being very old, legacy installations in enterprises. In both cases I'm making slow and steady progress to getting them up to 7.x or 8.x so that we can benefit from engine improvements etc).
> Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code
That. Is. The. Entire. Point. Of. Major. Versions.
A big red warning and culutral understanding of "stuff we said would be gone, that we gave you a year+ of notice on, is now gone, go read the migration notes if you've been sleeping under a rock."
You act like this is happening monthly? 8.0 came out in Nov 2020... , 7.0 was Dec 2015.
> I just don't understand why people accept this from their tools.
Actually our tooling is pretty nice. Between psalm, phpcs and rector, we have tooling that can forwarn of deprecations in use, and most of the time fix them automatically.
Should you always use PHP? No. But the debate on the nuances as to when to not use it doesn't tend to go well with those who just throw everything out the pram acting like PHP developers are insane because it's not a haskell/rust docker project.
Oh our company is fully on 7.x and looking to move existing projects to 8.x. (New ones being deployed to 8.x already)
The enterprise client is the one on 5.x (for an interop program for B2B order processing), in a secured intranet system behind firewalls (multiple, on occasion one of their teams breaks one while updating it and we lose access for a day) and a VPN.
They might get up to 7.x this year when they retire the server "our" VM within there is on and reprovision to some new metal.
But by all means, go try and bypass their procurement and change process. I'm sure they'll appreciate your insight into rapidly changing a component of one of their main revenue streams... Just let me grab some popcorn first :)
To be a little less cutting, its admirable to want to be clean and proper, to do it all the right way 100% of the time... But that ain't how the world works and you either bend to accommodate and try to do some good, or scream into the digital void... Your choice.
> this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code?
Great so let's just leave all of the legacy terribleness in it. Let's not address all the quirks and horribleness that sounded like a good idea at the time. Let's not let the language evolve.
For the longest PHP was really great with backwards compatibility, refused to address issues in the name of backwards compatibility. So it became the butt of the jokes it is today.
As you can imagine, I'm on the other end. Providing backwards compatibility is kept for a relatively long time, I don't think it's unreasonable to break changes with a good system (i.e. major version upgrades). In such cases, I welcome it.
> Great so let's just leave all of the legacy terribleness in it. Let's not address all the quirks and horribleness that sounded like a good idea at the time. Let's not let the language evolve.
Nobody is saying that. The golden rule of API design is do not break your customers.
The way you let a language or API evolve is by introducing a new API. For example, instead of changing the semantics of count() you might introduce len() and then try and not fuck it up this time.
> [...] where each major version upgrade breaks their code?
> [...] randomly change their APIs every couple of months [...]
This is just FUD. Breaking changes are announced long-term via deprecations, so they don't catch you out of the blue. Every major release of the runtime has three years of support, so nobody "randomly" changes their API every couple of months.
I find Google to be a funny example, by the way - picking that one company axing another project or API every other day.
this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code?
I just don't understand why people accept this from their tools. Imagine if Google would just randomly change their APIs every couple of months and then stop supporting the old ones. Nobody would use their stuff. But somehow the PHP community thinks this is perfectly normal.
It just boggles the mind.