search

opencontainers / runtime-spec

OCI Runtime Specification
http://www.opencontainers.org
Apache License 2.0
3.13k stars 535 forks source link

specs-go: Respect semver 2.0.0 #1221

Closed rata closed 8 months ago

rata commented 10 months ago

According to semver.org, the 2.0.0 spec, the pre-release info should be delimited by a "-" ("+" is for build info) and we already released 1.1.0, so increment the minor so this version compares to something bigger than 1.1.0.

Updates: #1220

thaJeztah commented 10 months ago

/cc @cyphar

thaJeztah commented 10 months ago

Note that v1.0.1-dev may not be a good choice either, as it would rank higher than v1.0.1-alpha.0 (or beta, etc).

One option could be to use v1.0.1-alpha.0, and create a tag after the (non-alpha) release is done.

In all cases, it's a bit of a "chicken-and-egg" situation, because SemVer versions are based on the content of the changes, and the content of changes is not yet known until an actual release is prepared (update Major, Minor or Patch, depending on the changes that are included).

cyphar commented 10 months ago
  1. SemVer uses MAY in the text describing pre-release versions: "A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version." As per RFC 2119, not following this is not a spec violation. Contrary to the PR description, it is not a "should" (even if it were a SHOULD, it still wouldn't be a spec violation).
  2. SemVer is concerned with versions that are actually shipped. We use +dev for the HEAD of our branch, which is not shipped. As far as I'm concerned, SemVer has nothing to say about this -- we could just as easily say that the version is "DO NOT USE" for non-released versions because it is not released. EDIT: In other words, "pre-release" in the SemVer spec refers to things like alpha and beta releases (as shown in the examples) -- it does not refer to the HEAD of a repo branch. If it did, most projects would be breaking SemVer with every feature commit on their main branch if they aren't updating the version number each time. The fact that Go lets you use the HEAD version of a library directly is an unfortunate misfeature that Go modules attempted to fix but still support because the community depends on this now -- SemVer was not designed with Go's peculiar "versions aren't real" mantra in mind.
  3. Switching away from -dev was intentional. As mentioned in the original PR which changed this, the old behaviour was suboptimal and needed to be changed. For one, -dev ranks higher than -alpha and -beta. It also has the frustrating behaviour of making emergency updates cause issues with spec validation tools because the version (according to SemVer) is different -- there is no ideal solution for the spec validation problem, but -dev is the worst solution. The only alternative solution that seems reasonable is to switch to the Go model (1.1.1-0.gitfoo+unreleased) but this has other downsides. If you feel that +dev is a problem, please help us come up with a solution other than the old one (which we moved away from for a reason).
rata commented 10 months ago

@cyphar

  1. And why you mention that? It is completely unrelated to what I say. Am I missing something? I just say we treat "1.0.2-dev" as older than "1.0.2", but on semver it isn't. I'm not saying something break without a pre-release info.
  2. But as I said, this is exposed to users: runc features in 1.1. exposed version 1.0.2-dev.

@thaJeztah thanks for the links, I've missed that. And I had a typo in my example when comparing "-dev" versions with "alpha.1", so I thought the comparisson worked fine, when it didn't :-D

rata commented 10 months ago

@cyphar

  1. Why not use 1.1.1-0.unreleased then? This compares to something bigger than 1.1.0, so users can see that is newer and it is smaller than all the pre-releases we might make (1.1.1-alpha, -alpha.1, beta, or even 1.2.0, all works fine)

I don't think using an unreleased version creates a new problem for runtime-tools. It only supports to validate the current spec-version vendored, so if the exact same version is vendored, it will work. If it isn't, it won't (same as with the curren "-dev" we have today).

rata commented 8 months ago

Now that we merged the way to expose the features, this is not so important to me. If indeed exposing in runc different specs but whose versions compare to equal is problematic (I wouldn't be surprised if it is), we can revisit this decision.