Update paths to v2

[cristaloleg]

No description provided.

[coveralls]

Coverage remained the same at 90.743% when pulling 2cd0101 on cristaloleg-patch-1 into 0ffb763 on master.

[siennathesane]

TBH we don't need to do path updates. When installing/downloading, if you call go get github.com/allegro/[email protected], you get it at version 1, and go get github.com/allegro/[email protected].

[siennathesane]

if you call go get github.com/allegro/[email protected]

Thinking about it, I'm not sure this would work since there is no go.mod.

[gracenoah]

I suspect that running go get github.com/allegro/[email protected] would add bigcache to your go.mod with the +incompatible suffix to work around the requirement for a /v2 suffix. I'm surprised that no tests failed without the v2 suffix though.
See https://github.com/golang/go/wiki/Modules#can-a-module-consume-a-v2-package-that-has-not-opted-into-modules-what-does-incompatible-mean

[cristaloleg]

@janisz please, have a look

[janisz]

I'm surprised that no tests failed without the v2 suffix though.

We need to enable modules on travis https://dave.cheney.net/2018/07/16/using-go-modules-with-travis-ci

[cristaloleg]

Huh, wait, why does it work on master? 🤔

[cristaloleg]

Or in this PR also, Go 1.x is 1.12.3 and modules aren't enabled by default

[cristaloleg]

No, wait, why does it work without explicit Go111MODULES ? ;D

[cristaloleg]

Ah, Travis is smart, we're outside of a GOPATH
https://travis-ci.org/allegro/bigcache/jobs/550658078#L437