[Bug] Use `semver 2.0.0` for naming release versions

[kallegrens]

Current Behavior

Releases seem to use year.month.day-format. This causes semver-based auto-update / ci systems to believe that going from, for example, 25.12.3 to 26.01.1 is a major (potentially breaking) change.

Expected Behavior

Instead use semantic versioning with structure major.minor.patch

Excerpt from the semver.org website

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes
2. MINOR version when you add functionality in a backward compatible manner
3. PATCH version when you make backward compatible bug fixes

---

Can't think of any downsides to semver, as the date is already captured in the release metadata.

---

As of the current release naming scheme, this tells me nothing about the impact of an update, requiring me to stop auto-updates for makemkv, and go and read release notes for EVERY update.

Steps To Reproduce

N/A

Environment

• OS:
• OS version:
• CPU:
• Docker version:
• Device model:
• Browser/OS:

Container creation

N/A

Container log

N/A

Container inspect

Anything else?

No response

[jlesage]

Yes, calendar versioning is an explicit choice: https://github.com/jlesage/docker-makemkv?tab=readme-ov-file#docker-image-versioning-and-tags

Semantic versioning doesn't make sense for a Docker container image, because it is composed of multiple softwares and libraries. So choosing when to increment the MAJOR/MINOR/PATCH is very difficult. Also, there is no notion of "breaking change": there is no case where an update of the image will make the container inoperable.

[kallegrens]

Not sure what you mean by

Also, there is no notion of "breaking change": there is no case where an update of the image will make the container inoperable

Of course there can be breaking changes because they propagate from upstream.

---

It seems that makemkv already uses semver anyway, so just follow that? https://www.makemkv.com/download/history.html

How many libraries or software are included in the image is irrelevant. What matters is the "user facing API", I.e., whether I as a user need to change some environment variable or volume config, for example.

I agree that it requires some effort if you don't suppose the makemkv versioning scheme is true semver already.

[jlesage]

By breaking change, I mean change to the Docker image that would cause the container to stop working after an update of the image. This should never occur, unless there is a bug.

It seems that makemkv already uses semver anyway, so just follow that? https://www.makemkv.com/download/history.html

The Docker image is more than just MakeMKV. It's a complete application stack. Most of the time, the image is updated while keeping the same MakeMKV version.

How many libraries or software are included in the image is irrelevant. What matters is the "user facing API", I.e., whether I as a user need to change some environment variable or volume config, for example.

Same thing here: most of the time, environment variables and volume configuration don't change with new image versions. So we cannot only rely on "user facing API". Also, I do think softwares included are relevant. Let's say noVNC is updated with a new feature (e.g. audio support). I guess that in this case, we would want to increase the minor version, even if the MakeMKV version remains the same ?

SemVer works well for libraries/APIs with clear notions of bug fixes, feature additions, and breaking changes. But for applications (which I consider this Docker image is), those distinctions are subjective and hard to apply consistently.

[alexindigo]

Just my 2 cents.

By breaking change, I mean change to the Docker image that would cause the container to stop working after an update of the image. This should never occur, unless there is a bug.

Theoretically it's possible outside of being a bug, and also, it's not only about container stopped working, but also, container not working as expected, for example, environment variable that controls dark mode vs light mode changes, then container would still work, but old/existing config wouldn't perform as expected, so it would be a "breaking change" in semver semantics.

[jlesage]

I agree that a change in behaviour could be considered as a breaking change.

Note that for this project, no release should be made if it is known to introduce changes that would alter the container’s behavior in an unexpected or unintended way.

[alexindigo]

@jlesage This makes sense, but also, there are libraries/apps inside container that may release new major versions, and while it's possible to have certain mapping between docker-compose config and in-container APIs, but I'd imagine there is non-zero chance, where it wouldn't work, and overall keeping this kind of mapping long term would be consuming more project dev time that necessary.