I can't tell if your comment is serious or not but in any case you're completely missed my point.

I'm talking about people who assume version 2.1 means something different from a version 1.2. Developers can bump version numbers in any which way they want and while some projects to have a documented standard for versioning; most projects do not. So consumers of software shouldn't base judgements solely on which digit is incremented in a version string.

Bu9t if you know the project they can be meaningful. E.g. how many Rust libraries make a decent effort at following SemVer or how the two digits of PostgreSQL have very specific meanings which always are respected (the first digit is the major version which may contain new features and break APIs while the second digit is only for bugfixes and is not allowed to introduce any new feature).

The thing is, if you’re running production services, particularly ones that need to be stable and secure, then you need to treat any version update with caution; even point versions on SemVer strings. You’d still need to deploy to dev and test first, you’d still need to do any security scans you’d normally do, etc.

The dev community have suffered malware before from point releases being released by new authors. And we’ve seen occasions in the past where a bug fix in a point release has inadvertently broken something else.

I guess you can argue that SemVar gives you an estimate about the likelihood something will break which might help when estimating JIRA tickets for the next sprint. But realistically you’d still have to follow a cautious release cycle even for updating point releases when on production environments.

This is why I think we need to get past the mindset of treating version strings as something trustworthy. They offer no guarantees whatsoever.