Is your feature request related to a problem? Please describe.

What I'm trying to achieve is having side-by-side importable client submodules for different major API versions. The API is likely to have limited functionality in the start for v2/v3 and users should be able to import v1 and v2/v3 at the same time to use functionality from all of them.

Describe the solution you'd like

Basically, I want to be able to generate go client library that is a submodule. Users should then be able to do:

import (
    v1 "github.com/bkabrda/someapi/someapi_v1"
    v2 "github.com/bkabrda/someapi/someapi_v1"
)

v1.DoStuffNotYetSupportedInV2()
v2.DoSomeNewStuff()

Describe alternatives you've considered

A clear alternative is using multiple separate repos, each with code for an individual major API version. I do want to go the way in this proposal for reasons listed below.

Additional context

I think there are several benefits of being able to do submodules:

• It becomes easier to maintain, update and release all submodules at the same time - e.g. do a bugfix of bug that goes across all major API versions in a single commit (and release)
• I do believe having code for multiple versions in a single repo is also easier for users to grasp as it doesn't require them to e.g. report issues against multiple repos and can just say "this feature is broken in all submodules"
• I think being able to generate a submodule could also be useful for different usecases (like having the code embedded in an application that actually uses the generated code and ships it as submodule)

In case this makes sense, I'd appreciate some guidance on what the name of the commandline argument (and/or config key name) for submodule should be.

Thanks!