v2 branch and module rename

[jrefior]

Per "semantic import versioning", introduced with go modules in go 1.11, incrementing the major version of a module above 1 requires a new import path. See:

In semantic versioning, changing the major version number indicates a lack of backwards compatibility with earlier versions. To preserve import compatibility, the go command requires that modules with major version v2 or later use a module path with that major version as the final element. For example, version v2.0.0 of example.com/m must instead use module path example.com/m/v2, and packages in that module would use that path as their import path prefix, as in example.com/m/v2/sub/pkg. Including the major version number in the module path and import paths in this way is called "semantic import versioning".

Module compatibility and semantic versioning

The preferred way to do this is usually to create a v2 branch, append /v2 to the module name (first line of the go.mod file), update import paths to include the /v2, and tag a new v2.x.x release. That should be all that's required. Imports that leave off the v2 will get the highest v1.x.x availlable, while imports that include the v2 will get the highest v2.x.x available.

See From Repository to Modules.

[garyburd]

Duplicate of #366. Please feel free to suggest a change that that works for applications that opted into Go modules and applications on Go 1.8 and earlier.

[jrefior]

Thanks I'll move my comment in there, and try to create a useful PR for it.

[jrefior]

Could you tell me a little more about the Go 1.8 and earlier issue, or refer me to an issue report? Thanks.

[garyburd]

See #363.

[garyburd]

https://travis-ci.org/gomodule/redigo/jobs/422783968