Why go module pseudo version have a specific version?

user_9239185 0
Viewed 676

I have a go.mod looks like

require(
   ...
   github.com/google/wire v0.3.1-0.20190716160000-66f78fc84606
   ...
)

Based on my understanding, if a package looks like that (yyyymmddMMSS-commit_id), which version should be v0.0.0 but not v0.3.1 as this example.

Could someone guide me how should I explain this? Does go mod ignore the v0.3.1- prefix?

go-modules go version
2 Answers

In fact there are 3 acceptable forms of pseudo-version:

  1. vX.0.0-yyyymmddhhmmss-abcdefxyz.
    when no earlier versioned commit with an appropriate major version before target commit

  2. vX.Y.Z-pre.0.yyyymmddhhmmss-abcdefxyz
    when most recent versioned commit before the target commit is vX.Y.Z-pre

  3. vX.Y.(Z+1)-0.yyyymmddhhmmss-abcdefxyz
    when most recent versioned commit before the target commit is vX.Y.Z

Some more details about Managing Go Module Pseudo-Versions:
https://hackernoon.com/managing-go-module-pseudo-versions-in-go-113-412h30lw

user_138045310

It's the result of go get'ing a specific commit that exists in the tree after a semantic version tag:

go get github.com/google/wire@66f78fc84606

Pseudo versions are used not only when there is no version tag. As the official documentation about pseudo versions shows:

Pseudo-versions may refer to revisions for which no semantic version tags are available. They may be used to test commits before creating version tags, for example, on a development branch.

...

vX.Y.(Z+1)-0.yyyymmddhhmmss-abcdefabcdef is used when the base version is a release version like vX.Y.Z.

In this case, the repository does have semantic version tags. The base version here is v0.3.0, and by getting a specific commit (66f78fc84606) that exists after v0.3.0 and before the next one v0.4.0, you end up with:

github.com/google/wire v0.3.1-0.20190716160000-66f78fc84606

user_41088030
Related