SemVer is partly social and partly technical. -- Socially, with semver you're promising that the software (especially its interface) won't change too much. Tech

SemVer is partly social and partly technical. -- Socially, with semver you're promising that the software (especially its interface) won't change too much. Technically, if function signatures change, or if implementation behaviour significantly changes (in ways that'd break old code), you want semver to indicate that. Nix's hashing of inputs solves a different problem. It wants to make sure you can have slightly different builds of packages available to the system. > ...since `patch` updates do not change observable behavior... Sure, the social guarantee of semver isn't enough to guarantee reproducible packages the same way Nix does, sure. But that doesn't mean that someone depending on v1.1.1 of a package would be happy to suddenly see v2.0.0, or that they'd be unhappy to see v1.1.2.