alt Hacker NewsSemantic versioning is for APIs, not for functionality. So it's for developers consuming that API (whether a library, or a service).
For releases in production, use a calendar version. v2025-11-02 is a clear release tag. Add preciseness as required. There should be a SBOM/Manifest (Bill Of Materials) of the versioned major components and configuration for that overall release.
For users, it depends on the type of user and what they expect. Their focus is on functionality. So when there's a new feature, bump the number.
It's a bit like the car model. It can be random extension letters like "-X", or "6Si".
Replies
Developers are "users" (of a library, API, tool...), and "API functionality" is a subset of "functionality": what purpose would such distinction serve?
For example, in end user desktop software (say a text editor), how would you indicate a security bug fix for an old version v2023-11-02 without forcing users to pay for a new version of v2025-09-15?
Again, versioning is a tool, and depending on the release structure of a project, SemVer might work well or it might not (including for APIs/libraries).
Oracle used to do that, didn't they?
So, amongst others, they had Oracle 8i at the height of the dot com boom (i for "Internet"), then a few years later when clustering became big news there was Oracle 10g (the g standing for "grid", I think?), and so on.
Actually, it looks like they might still be doing it - I just checked, and their current version is 23ai...