Impact of Patches on Version Naming

I was wondering if applying patches influences a package’s version. The Package naming, Versioning and Patches sections on pkgs/ make no mention to any kind of change to package’s version if a patch is applied, only if a non tagged version of a commit is used — -unstable-YYYY-MM-DD.

I ask this, because if a package foo at version x.y.z has a patch 001 applied to it, it is no longer foo at x.y.z — with the exception of nix specific patches, e. g., fixing absolute paths, since the package needs it to work on nix.


In nixpkgs it is since we don’t need to bump the version number to trigger a rebuild.


To elaborate what @Sandro said, in Nix, the actual “version” is the large hash in front of each package name:


The string in the end is an arbitrary string that only exists to inform us humans what to expect of the derivation contents. The version numbers bears no significance w.r.t. being a number.

Changing patches, dependencies or anything of significance about a package will produce a different hash and therefore automatically be a different “version”.
We do not need to bump patch levels like other distros do.

1 Like

It might be good for repology if we automatically append a patch number based on based on the length of patches and number of substituteInPlace during patchPhase. Then we’d distinguish between rebuilds triggered by changed inputs vs rebuilds triggered by a patch

What is Repology supposed to do with that information? They don’t track patches to my knowledge.

But they do compare version numbers, and we may get considered outdated since an other distro bumped the patch version. Anyway the idea is kinda silly

Other distros then just invent version numbers of softwares which don’t exist upstream.

Also decreasing patches would also decrease the version number which is not what we won’t. Also tracking a version number in some extra metadata also seems pointless in the case of nix.