How would you indicate to a package manager that something is a critical bugfix release, rather than a non-critical feature release?
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.
For the cases where we do distinct security updates (e.g. kernel updates), we seem to do them using all sorts of hacks.
Maybe we just need a superset of semver, that can encode more than just the "newness" dimension, but also the "criticality" dimension?
> 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
I use a commercial OS, so there's a company out there where some well-paid professional decides which updates need to be pushed out ASAP and which ones can wait until next patch Tuesday.
I'm not sure if that person / team can ever be replaced by modifications to a version numbering scheme.
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.
For the cases where we do distinct security updates (e.g. kernel updates), we seem to do them using all sorts of hacks.
Maybe we just need a superset of semver, that can encode more than just the "newness" dimension, but also the "criticality" dimension?