Hello,
We build this module in our internal CI, package it as a versioned .deb, and bake it into immutable production images. To make the image auditable and to document exactly what was built and installed, we need to specify the version (tag) that should be pulled.
Until now we stuck to the latest tagged version, v1.4.0. Recently we hit a kernel warning on our systems and looked into this repo to see whether a newer release might already fix it.
While doing so we noticed that the tag names don't match the version strings they ship:
| ref |
commit |
MODULE_VERSION |
dkms.conf PACKAGE_VERSION |
tag v1.4.0 (latest release) |
26e404a, 2025-02-04 |
1.4.1 |
1.4.1 |
main |
3404e5d, 2025-10-17 |
1.4.2 |
1.4.2 |
So a module built from the release called "1.4.0" reports 1.4.1 under modinfo. There is no v1.4.1 tag, and no v1.4.2 tag either.
We also realized that main is 3 commits ahead of the latest release and has been untagged since October 2025. Both version strings there are now 1.4.2:
7681846 2025-10-17 Update dkms.conf PACKAGE_VERSION 1.4.1 -> 1.4.2
41ae6e7 2025-10-17 fix potential missing lock MODULE_VERSION 1.4.1 -> 1.4.2
3404e5d 2025-10-17 Update crono_kernel_module.c ("fix old branch")
Our guess is that v1.4.2 was intended as a release and creating the tag was simply missed. Is that correct?
Our questions:
- Which is the recommended way to get a stable release for production use, the latest tagged release, or
main? Tracking "latest main" isn't really an option for us, since we have to pin something. At minimum we would need to pin a specific commit.
- If
v1.4.2 was indeed intended, could you tag 3404e5d retroactively?
- Would you consider a short note in the
README stating which source you recommend for production?
- Is this GitHub repo the canonical source for the Linux driver, or do you distribute it elsewhere as well? Possibly already packaged for the major distros (
.deb/.rpm/…)? We just want to be sure we're tracking the source you actually maintain for production users.
Many thanks in advance!
Hello,
We build this module in our internal CI, package it as a versioned
.deb, and bake it into immutable production images. To make the image auditable and to document exactly what was built and installed, we need to specify the version (tag) that should be pulled.Until now we stuck to the latest tagged version,
v1.4.0. Recently we hit a kernel warning on our systems and looked into this repo to see whether a newer release might already fix it.While doing so we noticed that the tag names don't match the version strings they ship:
MODULE_VERSIONdkms.confPACKAGE_VERSIONv1.4.0(latest release)26e404a, 2025-02-041.4.11.4.1main3404e5d, 2025-10-171.4.21.4.2So a module built from the release called "1.4.0" reports
1.4.1undermodinfo. There is nov1.4.1tag, and nov1.4.2tag either.We also realized that
mainis 3 commits ahead of the latest release and has been untagged since October 2025. Both version strings there are now1.4.2:Our guess is that
v1.4.2was intended as a release and creating the tag was simply missed. Is that correct?Our questions:
main? Tracking "latestmain" isn't really an option for us, since we have to pin something. At minimum we would need to pin a specific commit.v1.4.2was indeed intended, could you tag3404e5dretroactively?READMEstating which source you recommend for production?.deb/.rpm/…)? We just want to be sure we're tracking the source you actually maintain for production users.Many thanks in advance!