releases: use +dev as in-development suffix

[cyphar]

Under SemVer, the suffix "-dev" actually indicates a pre-release, meaning the way we've been using the suffix indicates that "1.0.0-dev" is older than "1.0.0" when we've used the suffix to indicate the opposite.

With most package managers, the "+dev" suffix correctly indicates that the version is newer (i.e. 1.0.1 > 1.0.0+dev > 1.0.0), though under SemVer "+dev" build tags must be ignored when doing version comparisons (meaning 1.0.0+dev == 1.0.0 under SemVer). However, from a SemVer perspective the unreleased version is inarguably closer to being equal to the last release than being older than it. As a specification we also allow extensibility of various parts, meaning that if someone uses an as-yet-unreleased version it seems reasonable to me for it to be treated as the same (from a SemVer perspective) as the last released version it's based on.

The other option would be to continue to use "-dev" as a suffix but bump the rest of the version number to the next version we plan to release, but this could also cause issues (we could have a "pre-release" for a release that never happened). Using "+dev" seems more sensible.

Switching to "+dev" also matches the way runc and umoci are versioned, and allows downstreams that use as-yet-unreleased versions of our specs to have their spec versions be treated as the same as the released version by other consumers.

Signed-off-by: Aleksa Sarai asarai@suse.de

[thaJeztah]

bump the rest of the version number to the next version we plan to release

I think this would be most accurate, but the caveat here is that technically we wouldn't know what the next version is, because with SemVer, the version depends on the changes included (whether it would be a major, minor, or patch update).

Go modules "solves" this by preemptively incrementing the patch version (last digit), which I guess would be a "safe" choice as long as it has a pre-release suffix. Note that -dev would be a poor choice for that (as it would sort higher than -alpha and -beta 🤔

[cyphar]

Yeah bumping the patch (and then putting -0-unreleased or -0+unreleased since numerical pre-release identifiers are always older than alphanumeric ones and -0 is the smallest) would get us somewhat better version ordering under SemVer but at the moment runtime-tools gives an error if the version doesn't exactly mention the spec version it was compiled with (and other tools might do the same thing).

This might be a somewhat esoteric issue, but for umoci this would mean we could never vendor a non-released version of a spec (something we've had to do quite a lot -- possibly more often than we've vendored released versions of image-spec and runtime-spec 😅) because it would cause oci-runtime-tool validate to fail. Obviously runtime-tool will need to have this behaviour fixed, but ignoring +dev seems like it would cause far fewer issues for runtime-tool than trying to get it to treat a "fake" pre-release nicely. (I personally think the behaviour needs to be completely reworked but I'm not entirely sure how to handle all the possible version combinations... At least +dev will only affect this particular case and not all of the other runtime-tool+runtime-spec version combination cases.)

Also having a 1.0.3-0+unreleased version which is followed by a 1.1.0 release seems a little odd to me but I guess it doesn't really matter if the version is fake if everything else is fake. 😅

[tianon]

I'm struggling to understand why this is important 😅

We don't ever actually release with a -dev suffix, it's just in the code as an indication to library consumers that they're not consuming a release version. Are there implementations that are doing version comparisons on this value (or on places this value gets embedded as-is)?

If so, we could do something like (dev) (space + "(dev)") as a very clear indicator that this isn't a relevant part of the actual intended version number and that the embedded version isn't actually a released version of the spec.

[cyphar]

In theory people shouldn't import a non-released version of the spec, in practice everyone does it at least some of the time. runc spec has generated a config.json with a -dev suffix on the version field for a long time, and runtime-tools cannot handle this (because it requires the version be identical to its internal version).

[AkihiroSuda]

Can we merge this?

[AkihiroSuda]

I'd like to release v1.1.0-rc.3 soon with this and #1191

[thaJeztah]

LGTM

but indeed, I don't think anything should realistically depend on this field in pre-releases, other than for "informational purposes" (otherwise it should better be propagated with an actual git reference)