Migrate to Go Modules

[marwan-at-work]

This PR migrates the package to Go Modules and updates the path according to Semantic Import Versioning

Generated by https://github.com/marwan-at-work/mod

[garyburd]

This PR breaks compatibility with Go 1.8 and below.

[marwan-at-work]

@garyburd yes, totally up to you if you'd like to accept that or not :)

[garyburd]

Is there a way to add Go module support and retain backwards compatibility with older versions of Go?

[marwan-at-work]

@garyburd go 1.9.X and 1.10.X (x being latest) are backwards compatible. They can still import your library without the vX suffix. But otherwise, 1.8 won't work unless you copy and paste the code into a vX directory (or type alias things there) which is not a fun thing to do.

[elithrar]

Go 1.9 was released in August 2017 - only 1 year ago. Since modules are only "experimental" in Go 1.11, we could hold off until Go 1.12 (when they are first-class), which is scheduled for Jan 2019.

Packages that declared a >= v2.x on the "vanilla" import path are effectively incompatible with modules. I believe @natefinch ran into this with mage and @markbates with Buffalo.

[natefinch]

yeah, so I was actually wrong.... with the latest patch of 1.9 and 1.10, those tools understand how to read go.mod... so if your code is on v2, but your import path doesn't include v2.... the go tool will figure it out if you put

module github.com/foo/bar/v2 

in the go.mod, and it'll use the v2 branch of the repo.

At least, that's what I've been told by reliable sources.

[natefinch]

(but also if you want to be compatible with go 1.8 or earlier, you need a physical /v2 folder, because those tools weren't updated to read the go.mod and don't know)

What I'd do: try it out before merging.

[garyburd]

What are the downsides of not migrating to Go Modules?

[marwan-at-work]

@garyburd for redigo not much.

The upside from introducing Go Modules is that the Go Command now recognizes your dependencies and can resolve them appropriately when users use redigo in their own systems. But since redigo does not have any dependencies it seems like, then you're fine.

Another one, is that it's just a migration thing. Which can wait until 1.12 :)

[bjm88]

I would vote to do it, if I recall a referenced import path/module got renamed on this project and it broke being able to use it briefly. I believe things like that wouldn't happen in the go 1.11 world. Its been a long time coming that go needed a proper module management tool standard. From what I've seen after some grumbling, the community is getting behind vgo's integration and seems very useful. It also better supports monolithic repos that are totally mixed tech stacks and outside GOPATH, death to GOPATH dependence is good.

[garyburd]

@bjm88 Importers using Go 1.8 and below will vote against this PR.

To all: Will this work?

• Remove redigo/internal by copying what's needed to redigo/redis and redigo/redisx.
• Remove the import comment from the package declaration.
• Update _test.go and redigo/redisx files to import github.com/gomodulue/redigo/v2/redis instead of github.com/gomodule/redis. Use build tags to disable these files on Go 1.8 and below.
• Add the go.mod file.

With this change, redisx and some tests are lost on Go 1.8 and below, but redigo/redis will continue to work.

[marwan-at-work]

@garyburd as another option: is it acceptable for users of 1.8 and below to simply stick to the current major version of redigo until they are ready to migrate Go 1.8 to 1.9 or above?

[garyburd]

It is not acceptable to require users to change how they fetch the code for this package. This includes Go 1.8 users who fetch the package using go get.

I want feedback from Go module experts on my proposal above.

[garyburd]

Let's continue discussion in #366.