[e12e]

This is especially true as projects age; i recently ran into yet another bug installing dependencies for a rails app, because of a patch-version change on a small library had a bug that manifested with our otherwise old/legacy stack.

I could see a similar situation for projects stuck on older version of node, lodash or whatever, where some tiny component break everything.

Its always fun when you have a known good build, make a change and trigger an error - only to realize the error is in your build system/dependency graph due to someone else doing testing on a different subset of versions than you need - not due to the change you just did.

[TheRealPomax]

That sounds like you forgot to peg your version dependencies, though. No matter the age of your code, proper version pegging in an ecosystem that does not allow version deletions (something npm learned the hard way, but amazingly, something pypi allows to this day) ensures that things don't break until you intentionally bump versions.

[e12e]

I generally expect patch version bumps (0.8.0 to 0.8.1)to give me fixes I want, without regressions or new bugs.

[TheRealPomax]

Note that there aren't a lot of ecosystems where everyone follows semver rules. Even on the npm registry, patch version bumps can still very much break your code because there's no validation during publication. It's still on you to make sure you have tests set up that run when code or dependencies change, even for something as simple as a patch version bump.

Although specifically to your example of 0.8.0 to 0.8.1: that's exactly the kind of version that semver guarantees is not safe: major version 0 is the "unstable" version, and the minor/patch rules do not apply to it (see https://semver.org/#spec-item-4).