x/vgo: Strict adherence to semantic versioning

[jbrodriguez]

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?

Yes

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 (
	"github.com/jbrodriguez/actor" 1.0.0
	"github.com/jbrodriguez/pubsub" 1.0.0
	"github.com/labstack/echo" v3.2.6
)

What did you see instead?

module "mediagui"

require (
	"github.com/jbrodriguez/actor" v0.0.0-20170412170600-37e4989b0e3c
	"github.com/jbrodriguez/pubsub" v0.0.0-20170412143127-17eb44fbbab7
	"github.com/labstack/echo" v1.4.4
)

[kardianos]

I think the issue in this case is that when you use the import path "github.com/labstack/echo" 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 "github.com/labstack/echo/v3" and your package that consumes it would need to reference it as github.com/labstack/echo/v3.

[rsc]

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.

[myitcv]

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:

v3.2.6
3.2.6

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 github.com/labstack/echo 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?

[komuw]

@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