Closed cyphar closed 1 year ago
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
🤔
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 :sweat_smile:) 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. :sweat_smile:
I'm struggling to understand why this is important :sweat_smile:
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.
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).
Can we merge this?
I'd like to release v1.1.0-rc.3 soon with this and https://github.com/opencontainers/runtime-spec/pull/1191
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