Bump go package to v2

[colin-axner]

Summary

We want to do a v2 release with #350, since this contains API breaking changes, we should follow go semantic versioning by bumping our package version as well. The go.mod file will read:

module github.com/cosmos/ibc-go/v2

All imports will need to change. I think this will be beneficial long term as it'll allow us to reference old code/structures when we need to maintain backwards compatibility

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[fedekunze]

why do you need to update the go package too?

[colin-axner]

why do you need to update the go package too?

This way we can import old code when we need to maintain backwards compatibility. This is especially useful for protobuf definitions which might change. For example, if the client state proto definition changes, we may want to import the v1 definition/implementation and decode the client state bytes into that definition for connections which cannot use the newer definition. We ran into this issue changing the version of solo machine which required migration code to reimplement the solo machine interface, if the migration code actually needed to use any of the interface functions, we would have had to maintain duplicate code, much easier to import.

Having separate histories for each version of this go module may prove useful for external clients as well.

This follows the golang module version, specifically when handling major version increments:

A major version update to a number higher than v1 will also have a new module path. That’s because the module path will have the major version number appended, as in the following example:

module example.com/mymodule/v2 v2.0.0

A major version update makes this a new module with a separate history from the module’s previous version. If you’re developing modules to publish for others, see “Publishing breaking API changes” in Module release and versioning workflow.

gaia does this as well. Happy to discuss the pros/cons, but changing imports per major version jump seems like low overhead for the potential benefits