Use `semver 2.0.0` for release versions?

[kallegrens]

Hello!

Nice project you have here! It would simplify integration with automatic update tools if timetagger used semver 2.0.0 for release versions (major.minor.patch). Read more here if you like: https://semver.org/

[almarklein]

Can you explain how semver would help for an application like timetagger? I can see how it helps for libraries and api's, but less so for apps ...

[kallegrens]

Forgive me for using ChatGPT when answering. Just a bit tired after a long week.

Hi @almarklein,

That's a good question. While SemVer's value is clear for libraries, it significantly benefits users of self-hosted applications like timetagger by providing predictable updates.

SemVer (major.minor.patch) signals the impact of a release: PATCH for backward-compatible bug fixes, MINOR for backward-compatible features, and MAJOR for potentially breaking changes.

This predictability is crucial for users managing their own deployments. It allows them to:

1. Update Safely: Know whether an update is low-risk (patch, minor) or requires attention (major).
2. Integrate with Tools: Tools like Docker Compose and Helm charts can leverage SemVer tags/constraints (e.g., image: timetagger:1.2 or version ranges >=1.2.0 <2.0.0) to automate patch/minor updates safely while requiring manual steps for major versions. This gives users control and reduces unexpected breakage. For you as a maintainer, using SemVer provides clear communication with your users and can reduce support issues related to surprise compatibility problems.

It turns version numbers into a valuable guide for users managing their timetagger instances.

Thanks again for considering it!

Best regards,

kallegrens

[kallegrens]

Also, it becomes extra relevant when using automatic docker pulls with for example watchtower or renovate where constraints can be made to auto-update on .patch or .minor, but not on major releases.

[almarklein]

So, IIUC the idea would be that the server component of timetagger does not introduce breakage because of port numbers or env vars and whatnot. I can see the point, but semver is not waterproof for solving that (see e.g. https://hynek.me/articles/semver-will-not-save-you). I kinda like the idea of Effver for that reason.

I think it makes sense to split up this repo into separate projects for the API server and application, in which case using semver/effver for the server, and caldev for the app makes sense.