Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/vgo: Strict adherence to semantic versioning #24007

jbrodriguez opened this issue Feb 21, 2018 · 4 comments


Copy link

commented Feb 21, 2018

What version of Go are you using (go version)?

go version go1.10 darwin/amd64 vgo:2018-02-20.1

Does this issue reproduce with the latest release?


What operating system and processor architecture are you using (go env)?

Does not apply

What did you do?

Ran vgo build on my project.

The issue seems to be hat although some libraries have a tag on github, since it's not strictly semantic version (with the 'v' prefix), it doesn't recognize the library version.

I guess the issue with labstack/echo, has to do with the issue about the only v1 and v2 support so far (#23954).

What did you expect to see?

module "mediagui"

require (
	"" 1.0.0
	"" 1.0.0
	"" v3.2.6

What did you see instead?

module "mediagui"

require (
	"" v0.0.0-20170412170600-37e4989b0e3c
	"" v0.0.0-20170412143127-17eb44fbbab7
	"" v1.4.4

@gopherbot gopherbot added this to the vgo milestone Feb 21, 2018


This comment has been minimized.

Copy link

commented Feb 22, 2018

I think the issue in this case is that when you use the import path "" it assumes you want a v0 or v1 import. For a v3 import to work the echo package would need a go.mod file that contains module "" and your package that consumes it would need to reference it as


This comment has been minimized.

Copy link

commented Mar 30, 2018

Right, vgo used the latest labstack/echo which is v1.4.4, and it didn't find the tags in jbrodriguez/* because those did not begin with v. To avoid ambiguity, there needs to be a single spelling for each tag, and we require the leading v.

As for echo, what @kardianos said is correct. I'd like to make things so that if you were to change that line to say v3.2.6 and rerun vgo build, it would replace it with a pseudo-version so that you can easily access the pre-module v3.2.6 code. That's #24056.

@rsc rsc closed this Mar 30, 2018


This comment has been minimized.

Copy link

commented May 27, 2018

To avoid ambiguity, there needs to be a single spelling for each tag, and we require the leading v.

@rsc I assume you're referring here to ambiguity that would potentially be introduced by having the two tags:


An interesting point raised in #vgo is that the Semver v2 spec dropped the following from the v1 spec:

When tagging releases in a version control system, the tag for a version MUST be "vX.Y.Z" e.g. "v3.1.0"

The irony, as pointed out in the Slack channel, is that the URL for the 2.0.0 semver spec include v2.0.0

This might be the reason that started dropping the v prefix for >= 3.2.2

Might it be worth considering allowing versions without the v prefix, and defining that, in light of the "relaxing" in the 2.0.0 semver spec, no v prefix "wins" over a v prefix?


This comment has been minimized.

Copy link

commented May 28, 2018

@myitcv hi, I think you should open a new issue to tackle this since the current one is closed.

I think vgo should atleast clarify which semver spec it will be following. Since if it decides to follow the latest semver spec, then the v prefix shouldn't be required.
Personally I think vgo should accept both vX.Y.Z and X.Y.Z .

but the bigger question I have is; what happens when semver releases a new spec v3 and they change the tagging policy, will vgo follow suit.
cc @rsc

@golang golang locked and limited conversation to collaborators May 28, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
6 participants
You can’t perform that action at this time.