Comment by rswail

Comment by rswail a day ago

Semantic 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".

roryirvine a day ago

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...

Reply View 1 reply

rswail 8 hours ago

Exactly.
There's nothing specific about the letters after Oracle's RDBMS versions, they're for marketing purposes.

Reply View | 0 replies

necovek a day ago

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).

Reply View 1 reply

rswail 8 hours ago

Semver is semantic. It tells you about the changes in the API, not in the implementation. So it's relevant to the users (ie developers) of that API.
If I fix a bug in the implementation that doesn't affect the API itself, the semver doesn't change.
So it works to define the versioning of an interface.
Release versioning (like vyyyy-mm-dd) is about SRE and configuration management, it's about documenting what is actually operating in production.
User versioning is about user expectations. If you're doing a security bug fix, then a) it should be free to users affected, and b) it should be documented as the reason for the release.
For a security bug fix of v2023-11-02, you can add a "hotfix" extension to the numbering so v2023-11-02.001 or equivalent.

Reply View | 0 replies