> Package managers (including snapd) basically just "think" in semver. Semver is one-dimensional: releases are arranged on a big line, and they'll know to auto-

> Package managers (including snapd) basically just "think" in semver. Semver is one-dimensional: releases are arranged on a big line, and they'll know to auto-update based on e.g. whether a given release is close to your current release on the line. This is NOT how semver works, though... each section has, well, semantic meaning. Some updaters might linearize, sure, and many developers run fast and loose with versioning, but semver is a graph of varying major, minor, and patch version numbers which change with their own semantics which can describe more than just newness Bump major -> y'all best be careful Bump minor -> something you care about maybe changed, read the changelog Bump patch -> we'll probably just fix some bugs patch releases could and should be backportable to other minor releases under the same major release if people care about stability of a module. I think that the "work from master" mentality that npm and GitHub UX has lead people to is one of a handful of reasons that prople misunderstand versioning strings... I agree that flagging criticality is useful, though. Linux packagers like YUM/DNF have had this for a while, even the ability to feed a CVE identifier or bug id in to the package manager to resolve them