Vgo requires a "v" prefix to recognize tagged releases

[dhui]

Git tags need a v prefix to be recognized as a Go module version
See: golang/go#24007 (comment)

e.g. for version 2.3.0, the git tag should be v2.3.0

[ivy]

Thanks for opening this issue. When this project first started, tags were created without the v prefix which I believe is perfectly compliant with SemVer 2.0.0. Your issue appears to be a problem with vgo which seems to only support SemVer 1.0.0. Reading the next comment in that issue you linked golang/go#24007 (comment), it seems like this problem wasn't been fully addressed. Until then, I don't think it's wise to change our tagging conventions if we don't have to. I've subscribed to the issue and will reopen this if they ultimately decide to enforce the current behavior. Personally, I think this is a bug.

In the meantime, you could try this workaround from golang/go#23954 (comment):

It's probably not a long term solution, but if you manually change the v1.1.0 to a pseudo-version in the go.mod file as defined in vgo-intro - Defining Go Modules, it will build successfully.

For example:

require (
	"github.com/gorilla/securecookie" v0.0.0-20170224193804-e59506cc896a
)

Sorry for the extra hurdle. I know this is less than ideal...

[dhui]

Thanks for looking into the issue!

The "suggested" workaround is already present in Go 1.11's tool chain. The problem w/ the workaround is that upgrades aren't honored. e.g. go get -u and go get -u=patch will pull the master branch instead of reading tags.
See: https://tip.golang.org/cmd/go/#hdr-Module_aware_go_get

For example, I originally pinned my dependency to this package to version 2.2.0 in go.mod. When I run go get -u, I expect to see no changes to my go.mod file. However, what happens instead is that my pin is ignored (due to the workaround) and it's updated to the latest commit from the master branch.

Please reconsider.
I also think Go's tool chain should support SemVer2 tags (e.g. no v prefix), but based on my linked comment, it seems unlikely that this will change in Go. So it's easier for packages to adopt Go's current version tagging scheme (requires v prefix).

[pedromorgan]

@dhui Am with YOU.. ...

All @ivy needs to do is tag both.. = cool workaround for everyone ? knot ?

[pedromorgan]

@ivy Please don't close issues, but leave open for discuss... maybe create labels

[ivy]

@dhui You'll have to fill me in a bit, I haven't personally made the switch to vgo yet so some of this is going to need more investigation on my part. So if I understand, that workaround solves the issue of initially go geting dependencies but updates to the latest master when running get -u? Is that because vgo ignores the pin entirely or because it only pays attention to what it considers a correct version tag?

In either case, I'm perfectly happy to consider tagging future releases with a v prefix but you should open an issue first on golang/go as was suggested in the original report golang/go#24007 (comment):

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 .

---

@pedromorgan I closed this issue under the assumption that this is a bug the Go team should address. Vgo is still a prototype, last I checked and I don't want to change the release policy without carefully weighing the decision. I think we can both agree that this issue's worth reopening if that turns out not to be the case. Personally, I don't think that's likely though, given their discipline of never breaking backwards compatibility. 🤷‍♀️

[dhui]

Modules have been merged into Go 1.11 and will automatically be enabled if your project lives outside of the GOPATH and has a go.mod file.

I believe that there are 2 ways to "support" modules:

1. Use v prefix when tagging releases with SemVer.
   • Doing so will mark the module as incompatible but a project consuming the module will still be able to use module tooling with the expected behavior
2. Embrace modules by tagging releases with v prefix (with SemVer) and creating a go.mod file in the project.
   • For go-mail/mail, you'll need a v2 postfix in the module path.

[ivy]

@dhui I just tagged v2.3.0 with support for Go modules. Let me know if this fixes your issue.

After some others mentioned how this issue was stopping them from moving forward, I changed my mind on the SemVer 1 vs. 2 issue. Sorry for the inconvenience, I needed some time to read up on it. 😓

[dhui]

@ivy Thanks for fixing and following up!

v2.3.0 works well for me
I noticed that some code is still using the old import: gopkg.in/mail.v2

$ go mod why gopkg.in/mail.v2
# gopkg.in/mail.v2
<REDACTED>
github.com/go-mail/mail/v2
github.com/go-mail/mail/v2.test
$

This results in different versions of mail being pulled in which is unnecessary as one version is only used for tests

$ git grep /mail go.sum
go.sum:github.com/go-mail/mail/v2 v2.3.0 h1:wha99yf2v3cpUzD1V9ujP404Jbw2uEvs+rBJybkdYcw=
go.sum:github.com/go-mail/mail/v2 v2.3.0/go.mod h1:oE2UK8qebZAjjV1ZYUpY7FPnbi/kIU53l1dmqPRb4go=
go.sum:gopkg.in/mail.v2 v2.0.0-20180731213649-a0242b2233b4 h1:a3llQg4+Czqaf+QH4diHuHiKv4j1abMwuRXwaRNHTPU=
go.sum:gopkg.in/mail.v2 v2.0.0-20180731213649-a0242b2233b4/go.mod h1:htwXN1Qh09vZJ1NVKxQqHPBaCBbzKhp5GzuJEA4VJWw=
$

Once that import is fixed, you can probably clean up .travis.yml

Also, as an FYI, I've learned that consumers can work around module version issues by using the replace directive.

[ivy]

@dhui Good catch! I believe that's example_test.go using the old import path. I'll have a fix up soon depending on the outcome of #39.