Move library implementation into v2 subdirectory

[dgellow]

So, after being confronted to the following error from the go mod command line tool, I see that we didn't do the migration work required when moving from no-modules to go modules. The error:

/Users/sam/Development/Go/gopath/src/github.com/optiopay/micro/go.mod:24: require github.com/optiopay/kafka: version "v2.1.0" invalid: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

I did a bit of research, what I now understand is that go modules for versions greater than 1 require to have the source code in a vN subdirectory, where N is the major version.

Links:

• https://stackoverflow.com/a/53380636.
• That's also something hinted in https://blog.golang.org/migrating-to-go-modules but not explained in details
• https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

I guess that this PR will break compatibility for old versions of golang that don't support modules.

[dgellow]

@e-max I didn't move kafkatest to v2 directory because it isn't supported anymore as far as I understood. Also, testkeys is just some assets for our tests and should be the same regardless of the library version, I kept it at top level of the repo.

[NexoMichael]

LGTM

[dgellow]

Hmm, do I also have to move the go.mod and go.sum files to v2? What do you think?

[dgellow]

Ok, I found https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher, emphasis is mine:

Major subdirectory: Create a new v3 subdirectory (e.g., my/module/v3) and place a new go.mod file in that subdirectory. The module path must end with /v3. Copy or move the code into the v3 subdirectory. Update import statements within the module to also use /v3 (e.g., import "github.com/my/module/v3/mypkg"). Tag the release with v3.0.0.

• This provides greater backwards-compatibility. In particular, Go versions older than 1.9.7 and 1.10.3 are also able to properly consume and build a v2+ module created using this approach.
• A more sophisticated approach here could exploit type aliases (introduced in Go 1.9) and forwarding shims between major versions residing in different subdirectories. This can provide additional compatibility and allow one major version to be implemented in terms of another major version but would entail more work for a module author. An in-progress tool to automate this is goforward. Please see here for more details and rationale, along with a functioning initial version of goforward.
• Pre-existing dependency management solutions such as dep should be able to consume a v2+ module created in this way.

[e-max]

@e-max I didn't move kafkatest to v2 directory because it isn't supported anymore as far as I understood.

I had this impression too, but just recently we had a couple issues submitted in this repo by people who use kafkatest

[dgellow]

Does that mean that you would like to continue maintaining it as part of v2?

[NexoMichael]

LGTM

[dgellow]

@e-max So, I moved kafkatest to v2/kafkatest.