Surely this is a side-effect of semantic versioning? Any breaking change means a new major version number. That doesn't necessarily mean a ton of maintenance work.
For example: the base version of Safari being targeted is now the version from 2020 instead of 2019. That's a breaking change. For the vast majority of people it is going to require zero work but for a minority of people (specifically targeting old iPad versions, perhaps) it's not something they can be automatically opted into.
In practice, it doesn't really matter. Every breaking change increases risk as an end user and reduces the likelihood that I'll upgrade at all, instead of switching to something else more stable.
Then again, the number of times I've been bit by a "minor" breaking change causing massive headaches during upgrades has made me somewhat jaded on the topic. No matter how great the tool, I will always prefer something more stable for real, production work.
Every breaking change increases risk as an end user and reduces the likelihood that I'll upgrade at all, instead of switching to something else more stable.
I understand this perspective and don't wish to sound negative but with this approach it's possible that web development simply isn't for you. The volatility in these tools is a reflection of the volatility in client browsers: they're upgraded constantly with new features that benefit the end user. I'm sending images to clients using WebP instead of PNG because the bandwidth savings are huge. That was a "breaking change" to my publishing pipeline but it was worth the investment.
At the same time you can keep using Vite 3. I've dug out old projects using old versions of Webpack and they've still functioned fine.
I feel like it depends on who you users are. At work, we cared a long time about IE users. Nowadays we don't, we would care about safari, but as that browser is untestable, we don't. So you either use chrome or Firefox LTS+ or the newest safari. Nothing else matters now.
Comments
Surely this is a side-effect of semantic versioning? Any breaking change means a new major version number. That doesn't necessarily mean a ton of maintenance work.
For example: the base version of Safari being targeted is now the version from 2020 instead of 2019. That's a breaking change. For the vast majority of people it is going to require zero work but for a minority of people (specifically targeting old iPad versions, perhaps) it's not something they can be automatically opted into.
In practice, it doesn't really matter. Every breaking change increases risk as an end user and reduces the likelihood that I'll upgrade at all, instead of switching to something else more stable.
Then again, the number of times I've been bit by a "minor" breaking change causing massive headaches during upgrades has made me somewhat jaded on the topic. No matter how great the tool, I will always prefer something more stable for real, production work.
I understand this perspective and don't wish to sound negative but with this approach it's possible that web development simply isn't for you. The volatility in these tools is a reflection of the volatility in client browsers: they're upgraded constantly with new features that benefit the end user. I'm sending images to clients using WebP instead of PNG because the bandwidth savings are huge. That was a "breaking change" to my publishing pipeline but it was worth the investment.
At the same time you can keep using Vite 3. I've dug out old projects using old versions of Webpack and they've still functioned fine.
I feel like it depends on who you users are. At work, we cared a long time about IE users. Nowadays we don't, we would care about safari, but as that browser is untestable, we don't. So you either use chrome or Firefox LTS+ or the newest safari. Nothing else matters now.