Possible bug in turning versions into pseudo-versions

[volf....@gmail.com]

Hello,

recently I've created a new golang library and released it with pre-release
version first to catch any bugs before doing proper 1.0.0 release.

The pre-release version was called 1.0.0-pre-release+1 , which according
to https://semver.org/ should be completely legal semver. If I read the
grammar correctly, it should fall under

<version core> "-" <pre-release> "+" <build>

with



<version core> being 1.0.0, which is obviously correct.



<pre-release> being pre-release, which should be ok
from this chain



<pre-release> ::= <dot-separated pre-release identifiers>

<dot-separated pre-release identifiers> ::=
<pre-release identifier>
| <pre-release identifier> "." <dot-separated pre-release identifiers>

<pre-release identifier> ::= <alphanumeric identifier>
| <numeric identifier>

<alphanumeric identifier> ::= <non-digit>
| <non-digit> <identifier characters>
| <identifier characters> <non-digit>
| <identifier characters> <non-digit> <identifier characters>

<identifier characters> ::= <identifier character>
| <identifier character> <identifier characters>

<identifier character> ::= <digit>
| <non-digit>

<non-digit> ::= <letter>
| "-"

so again, since all characters in pre-release fit into <non-digit>, that should
be ok as well.



<build> being 1 seems again obviously correct from

<build identifier> ::= <alphanumeric identifier> | <digits>



And despite the version being correct semver, it was mangled into pseudo-version
v1.0.0-pre-release.0.20200420093620-87861123c523. However, to quote from
https://github.com/golang/go/wiki/Modules#can-a-module-consume-a-package-that-has-not-opted-in-to-modules

> If the repository does not have any valid semver tags, then the repository's
> version will be recorded with a "pseudo-version" such as
> v0.0.0-20171006230638-a6e239ea1c69



I see basically 3 possibilites here:

1. Documentation is incorrect since only *subset* of semver is actually
supported.

2. There is bug somewhere in the semver parsing causing my version not to be
considered correct.

3. I cannot read Backus-Naur and my version is *not* correct semver.

Is there something else I did miss in this analysis?


W.

[Uli Kunitz]

The documentation provided by go help modules doesn't refer to semver.org and the Backus-Naur-Form there, so you cannot assume it is supported. The semver.org BNF doesn't support the leading v letter, so Go modules versions are anyway incompatible.

[volf....@gmail.com]

On Wednesday, April 29, 2020 at 6:57:55 PM UTC, Uli Kunitz wrote:

The documentation provided by go help modules doesn't refer to semver.org and the Backus-Naur-Form there, so you cannot assume it is supported. The semver.org BNF doesn't support the leading v letter, so Go modules versions are anyway incompatible.

I don't know about `go help modules`, but https://github.com/golang/go/wiki/Modules#modules has link to semver.org, in sentence

> Modules must be semantically versioned according to semver,

But if that link is a mistake and should be removed, where could I found what does go mean by "semver"?

W.

[volf....@gmail.com]

On Wednesday, April 29, 2020 at 6:57:55 PM UTC, Uli Kunitz wrote:

The documentation provided by go help modules doesn't refer to semver.org and the Backus-Naur-Form there, so you cannot assume it is supported. The semver.org BNF doesn't support the leading v letter, so Go modules versions are anyway incompatible.

And even `go help modules` mentions the semver.org now that I actually checked:

+ $ go help modules | grep semver.org -C2

See https://research.swtch.com/vgo-import for more information about

semantic import versioning, and see https://semver.org/ for more about

semantic versioning. 

W.

[Sean Liao]

go does mean semver.org when it refers to semver

> Modules must be semantically versioned according to semver[,...]

refers to what the numbers mean, the v prefix is required but not part of the version, more clearly explained in a faq on semver.org:

> Is “v1.2.3” a semantic version?

> No, “v1.2.3” is not a semantic version. However, prefixing a semantic version with a “v” is a common way (in English) to indicate it is a version number. Abbreviating “version” as “v” is often seen with version control. Example: git tag v1.2.3 -m "Release version 1.2.3", in which case “v1.2.3” is a tag name and the semantic version is “1.2.3”.

[Sean Liao]

semver point 10:

> Build metadata MUST be ignored when determining version precedence. 

chat log from slack:

> 22:29 bcmills Tags with metadata are not unique: there is only a partial order among them, not a total order.

> 22:30 In contrast, MVS requires a total order. (We can't choose between vX.Y.Z+a and vX.Y.Z+b, because SemVer defines them to be of equal precedence.)

> 22:31 So instead, we accept the tag but convert it to a very nearby pseudo-version, which restores the total-order property.

> 22:32 bcmills (We can't just reduce it to vX.Y.Z, because that version could have its own tag on yet another different commit.)

[volf....@gmail.com]

Aaah ok, so my usage should have been v1.0.0-pre-release.1 and v1.0.0-pre-release.2 ; and indeed,

when I've tested it it does work.

Thank you