Add go.mod file declaring proper semantic import path

[m90]

As the latest version is tagged as v2.x.x in git, using the package as a Go module will require importing it as github.com/patrickmn/go-cache/v2, otherwise it will show up as:

github.com/patrickmn/go-cache v2.1.0+incompatible

in a dependent's go.mod.

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

I know it's not pretty and introduces more things to maintain manually, but apparently it's what is supposed to be done in this context.

[patrickmn]

Yeah, this is pretty annoying. Ironically it's making me think we should just revert to <2.0.0 somehow, since the API difference between 1.0.0 and 2.0.0 is extremely small (*Item changed to Item with integer expiration times) and go-cache is essentially stable and has been for years. I realize the irony, but this seems preferable to asking all users of go-cache to add a version to their imports...

Unless I'm mistaken, if I merge this PR, the vast majority of people using Go 1.11 will suddenly revert to go-cache 1.0.0, something that's totally unnecessary and would decrease performance, all because of a tiny API difference in a corner nobody touches.

Is there a way to tell go mod to use 2.0.0 as the default?

[m90]

Unless I'm mistaken, if I merge this PR, the vast majority of people using Go 1.11 will suddenly revert to go-cache 1.0.0, something that's totally unnecessary and would decrease performance, all because of a tiny API difference in a corner nobody touches.

I don't think it'll be the vast majority right now as with Go 1.11 the module behavior is still opt-in (you have to work outside GOPATH or do GO111MODULE=on), so it should only hit people who do actively migrate. I would assume though that Go 1.12 turns on modules by default, so the issue you describe will most likely become an annoyance for everyone in 6 months time. So, yeah.

Is there a way to tell go mod to use 2.0.0 as the default?

I couldn't find anything on this topic. This is what go help modules will tell us about the situation (which leaves me wondering what the right thing to do is and what the actual implications of +incompatible can be):

Code written before the semantic import versioning convention
was introduced may use major versions v2 and later to describe
the same set of unversioned import paths as used in v0 and v1.
To accommodate such code, if a source code repository has a
v2.0.0 or later tag for a file tree with no go.mod, the version is
considered to be part of the v1 module's available versions
and is given an +incompatible suffix when converted to a module
version, as in v2.0.0+incompatible. The +incompatible tag is also
applied to pseudo-versions derived from such versions, as in
v2.0.1-0.yyyymmddhhmmss-abcdefabcdef+incompatible.

This is a similar issue in another repo I found: gofrs/uuid#44

Maybe it's best not to merge this now (as there are no pending updates from what I understand) and keep an eye on how other package authors / the community starts dealing with the problem at hand.

[m90]

This looks like a good thread on the topic: golang/go#25967 which sounds as if doing nothing is an ok choice in this situation (see this comment).

[patrickmn]

Thank you for the info.

I wish they'd gone with "nomod" or something over "incompatible". It makes it sound like go-cache is broken now.

[m90]

Yeah the naming is very unfortunate as it implies something is not working as intended. Anyways...