With kernel modules in particular, it's really useful to have the particular kernel version be part of their name so you can see from the failing derivation itself what kernel version they failed against.

Maybe we could make it a convention to add the kernel version to the derivation version.

i.e. version = "1.2.3-${kernel.version}";

I like that convention, and it's going to be actually true -- the version is a tuple of the package's version and the kernel for which it's intended. Now that #234651 has landed, we could even encode that in a kernel-specific mkDerivation.

The only major downside of this approach could be if someone wants to use finalAttrs.version for src.rev/src.tag.

If we had a kernel-specific mkDerivation, we could maybe store a moduleVersion and kernelVersion in finalAttrs though.

If we had a kernel-specific mkDerivation, we could maybe store a moduleVersion and kernelVersion in finalAttrs though.

Not only that -- we could use name to write out the name of the derivation however we wanted, while still requiring the users to use pname and version. The default mkDerivation behavior of name = "${pname}-${version}" is ours to change!

One thing I would like to note:

Most of our out of tree drivers rely on their repo's master branch, as in we mostly fetch their latest commit. Having a simple version like 0-unstable-2024-12-05 instead of 0-unstable-2024-12-05-${kernel.version} helps the automatic updater script (unstableGitUpdater).

As our kernel module maintenance is really bad without these scripts, we should look to fix that.

Haveing the kernel version included also breaks version comparision on sites like repology, which also get used by r-ryantm to check if a package needs an update.

I am thinking about having something like mkKernelModule, that exposes a normal version and it automatically appends the kernel version to the name of the drv.