Add go.mod with v3

[flibustenet]

No description provided.

[flibustenet]

For #43

[coveralls]

Pull Request Test Coverage Report for Build 137

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 99.143%

---

Totals
Change from base Build 135:	0.0%
Covered Lines:	347
Relevant Lines:	350

---

💛 - Coveralls

[coveralls]

Pull Request Test Coverage Report for Build 137

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 99.143%

---

Totals
Change from base Build 135:	0.0%
Covered Lines:	347
Relevant Lines:	350

---

💛 - Coveralls

[coveralls]

Pull Request Test Coverage Report for Build 137

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 99.143%

---

Totals
Change from base Build 135:	0.0%
Covered Lines:	347
Relevant Lines:	350

---

💛 - Coveralls

[coveralls]

Pull Request Test Coverage Report for Build 137

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 99.143%

---

Totals
Change from base Build 135:	0.0%
Covered Lines:	347
Relevant Lines:	350

---

💛 - Coveralls

[cristaloleg]

LGTM

[niaow]

I believe that we should add go 1.11 with modules support to travis. Not sure if that should go here. To do this, we would need to set GO111MODULE=on env variable. We have go tip in travis, so it would run on that.

[acln0]

I think 1.11 support for travis should go in a different PR. I filed #45 to that effect.

[niaow]

LGTM

[theckman]

Does v3 need to be in the file? Why can't the SCM tagging be used to provide the major version? It's provided as metadata on the repo, will be part of the natural release process, and subsequently won't be stale.

A secondary question, assuming it does need to be there is there a way we can think of to amortize the cost and have it be done automatically? How about flagging bad releases?

[flibustenet]

@theckman thanks for your question, i'm not so sure, will look more.

[flibustenet]

In the wiki:
https://github.com/golang/go/wiki/Modules#semantic-import-versioning

If the module is version v2 or higher, the major version of the module must be included in both the module path in the go.mod file (e.g., module example.com/my/mod/v2) and the package import path (e.g., import "example.com/my/mod/v2/foo").

[flibustenet]

For the second question, it's maybe related to golang/go#27009 (that confirm in the same time that we need the /v3 in go.mod) ?

[theckman]

We may just need to merge this, and deal with the cancer.

[flibustenet]

No pressure, it'll still be usable without go.mod. Feel free to wait if you think it's too early.

[acln0]

I think this can be merged as-is now, unfortunate as the situation may be.

This PR is about v3, but I thought I'd mention that we don't have a go.mod for v2, and I don't know how easy it would be to backport one, or if we even care to do so. In the meantime, module users who want v2 can go get github.com/gofrs/uuid@v2.1.0 and they'll get a require github.com/gofrs/uuid v2.1.0+incompatible in their go.mod. Oh well.