[Incipient]

I'm very confused on the debate of semver here - the fundamental principle seems very simple, and important.

"give me all updates to my core version that's still compatible"

Semver simply puts a 'protocol' to this - define your major version and off you go.

While in practice you could go and search for each and every library you use to check when/how they do breaking versions, but semver just allows matching a single number across the board - it makes it more consistent and error proof.

[BugsJustFindMe]

Because it's not "error proof". It's not even "more error proof". Relying on updates not breaking if the maintainer doesn’t intend it means relying on software being bug-free, and it should be immediately obvious that that would be a very very stupid thing to believe. Letting software you rely on change on its own is always dangerous no matter how much someone pinky promises that you can trust them to have thought of everything. Semver numbers are determined by humans who aren't oracles and therefore make mistakes all the time about what changes will break something for someone else. It may get people to think a little bit about whether they _think_ they're breaking something, but it's never safe to rely on that judgement because there's a good chance that they're wrong. And given that it's never safe to rely on that judgment, the process of pretending is worse than worthless; the pretense is inherently dangerous, because people start to unthinkingly trust it. If you care about things working, you pin and vendor (npm left-pad) your dependencies and only update a package if you _need_ to and only after explicit evaluation.

And if after reading that you think to yourself, "But BugsJustFindMe, I have unit tests that will catch semver mistakes!" I think you need to ask yourself what your unit tests tell you about semver code that they don't also tell you about non-semver code.

[Incipient]

I would absolutely agree with your approach for large-scale saas/highly publicised applications, especially when you have a team/people dedicated to security/versioning.

In small teams where you're focused on building features, being able to rely on semver for non-breaking versions has been very helpful/successful. I personally haven't encountered a breaking feature added to something that shouldn't be.

This also applies to our docker containers, using python 3.13-slim-trixie for example, and letting the patch version sort itself out.