'Minimal version selection' accepts that semantic versioning is fallible

May 20, 2018

Go has been quietly wrestling with package versioning for a long time. Recently, Russ Cox brought forward a proposal for package versioning; one of the novel things about it is what he calls 'minimal version selection', which I believe has been somewhat controversial.

In package management and versioning, the problem of version selection is the problem of what version of package dependencies you'll use. If your package depends on another package A, and you say your minimum version of A is 1.1.0, and package A is available in 1.0.0, 1.1.0, 1.1.5, 1.2.0, and 2.0.0, version selection is picking one of those versions. Most package systems will pick the highest version available within some set of semantic versioning constraints; generally this means either 1.1.5 or 1.2.0 (but not 2.0.0, because the major version change is assumed to mean API incompatibilities exist). In MVS, you short-circuit all of this by picking the minimum version allowed; here, you would pick 1.1.0.

People have had various reactions to MVS, but as a grumpy sysadmin my reaction is positive, for a simple reason. As I see it, MVS is a tacit acceptance that semantic versioning is not perfect and fails often enough that we can't blindly rely on it. Why do I say this? Well, that's straightforward. The original version number (our minimum requirement) is the best information we have about what version the package will definitely work with. Any scheme that advances the version number is relying on that new version to be sufficiently compatible with the original version that it can be substituted for it; in other words, it's counting on people to have completely reliably followed semantic versioning.

The reality of life is that this doesn't happen all of the time. Sometimes mistakes are made; sometimes people have a different understanding of what semantic versioning means because semantic versioning is ultimately a social thing, not a technical one. In an environment where semver is not infallible (ie, in the real world), MVS is our best option to reliably select package versions with the highest likelihood of working.

(Some package management systems arrange to also record one or more 'known to work' package version sets. I happen to think that MVS is more straightforward than such two-sided schemes for various reasons, including practical experience with some Rust stuff.)

I understand that MVS is not very aesthetic. People really want semver to work and to be able to transparently take advantage of it working (and I agree that it would be great if it did work). But as a grumpy sysadmin, I have seen a non-zero amount of semver not working in these situations, and I would rather have things that I can build reliably even if they are not using all of the latest sexy bits.

Comments on this page:

By lilydjwg at 2018-05-21 00:02:21:

So MVS ignores all later bug and security fixes? This worries me.

By cks at 2018-05-21 07:24:10:

That's one way to put how MVS doesn't advance version numbers by itself. Another view is that MVS declines to assume that any change is harmless or good unless you tell it explicitly (by forcing the version number to advance).

Semver or not, all we really know when a version number increases is that the version number has increased. By itself, we don't really know what this means, and we don't really know if the new version will give our package and our overall system the same results (or better results) than the old version.

(It would be nice if semver changed this, but it can't. All it can do is make it more likely that this happens by creating a social agreement that it should. This is fragile for various reasons, including that people have different views on whether certain sorts of changes are semver compatible or not. Is adding explicit error checks for things that don't work semver compatible, for example?)

Written on 20 May 2018.
« Modern CPU power usage varies unpredictably based on what you're doing
Bad versions of packages in the context of minimal version selection »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun May 20 22:30:49 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.