Backward compatibility: Add v2 branch mirrored last stable /v2 lib version.

[albenik]

Now it is impossible to use github.com/gocarina/gocsv/v2 with go.mod enabled library with may be used within non go.mod project, dep enabled project for example.

For example in github.com/gramework/gramework with github.com/gocarina/gocsv/v2, breaks dep enabled project in which it was imported.

Solving failure: No versions of github.com/gocarina/gocsv met constraints:
        master: Could not introduce github.com/gocarina/gocsv@master, as its subpackage github.com/gocarina/gocsv/v2 is missing. (Package is required by github.com/gramework/[email protected].)
        master: Could not introduce github.com/gocarina/gocsv@master, as its subpackage github.com/gocarina/gocsv/v2 is missing. (Package is required by github.com/gramework/[email protected].)
        v1: Could not introduce github.com/gocarina/gocsv@v1, as its subpackage github.com/gocarina/gocsv/v2 is missing. (Package is required by github.com/gramework/[email protected].)

And Go Module wiki described the backward compatible solution https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Major branch: Update the go.mod file to include a /v3 at the end of the module path in the module directive (e.g., module github.com/my/module/v3). Update import statements within the module to also use /v3 (e.g., import "github.com/my/module/v3/foo"). Tag the release with v3.0.0.

Go versions 1.9.7+, 1.10.3+, and 1.11 are able to properly consume and build a v2+ module created using this approach without requiring updates to consumer code that has not yet opted in to modules (as described in the the "Semantic Import Versioning" section above).
A community tool github.com/marwan-at-work/mod helps automate this procedure. See the repository or the community tooling FAQ below for an overview.
To avoid confusion with this approach, consider putting the v3.. commits for the module on a separate v3 branch.
If instead you have been previously releasing on master and would prefer to tag v3.0.0 on master, that is a viable option, but consider creating a v1 branch for any future v1 bug fixes.

[wcsiu]

I created a pull request for go module migration. Please also create a version tag on this repo, e.g. v2.0.0 for dependency management tools like dep and go mod. Hope it would help.