Proposal: Convert this repo to a Go module

[jhendrixMSFT]

Please add a 👍 reaction if you support this proposal. If you do not, please leave a comment describing why.

Now that Go modules have solidified and are on by default in Go 1.16 we are considering how we migrate this repo to officially support them (this is for our track 1 content; track 2 already supports modules).

In keeping with our current release strategy and version, the natural option would be to place a go.mod file in the root of the repo. However, given that we've already had dozens of major releases (v52.3.0 at the time of this writing), it would mean that the next major version would introduce semantic import versioning.

In go.mod:

module github.com/Azure/azure-sdk-for-go/v53

This would require consumers to update their import statements starting with v53 and beyond.

import github.com/Azure/azure-sdk-for-go/v53/services/foo/bar

While this "plays by the rules" it introduces a burden on consumers and we'd like feedback on the impact.

[johejo]

I think it's a good decision.
For reference, google/go-github did the same thing at v18, and is currently upgrading to v35.
https://github.com/google/go-github

[jhendrixMSFT]

Unfortunately this places a significant burden on consumers that use a large number of packages from this SDK. This was mentioned here on the negative impact it would have on Terraform.

[marchesir]

well at some point go may force the change, so not easy on anybody. i for 1 have an issue azure-sdk-for-go is required by terratest but where i work we use artifactory and as there is no go.mod it makes downloading hard as artifactory assumes .mod.

[jhendrixMSFT]

I tend to agree. It's a bitter pill but is likely inevitable. In addition, I recall there was talk about tooling to simplify updating a major module version.

CC @tombuildsstuff

[bcmills]

Regarding upgrade automation, I am aware of at least golang/go#32816 and golang/go#32014, as well as a couple of existing tools (https://github.com/icholy/gomajor and https://github.com/marwan-at-work/mod, but others may exist too).

[bcmills]

I'm also planning to address module aliasing and renaming (golang/go#26904) for Go 1.18 (due out EoY this year), and it's possible that that will include a way for an existing module to leave a “fowarding address”.

(More design work is needed, but migrating from one module path to another — including from an unversioned path to a versioned one — is an important use-case that we're actively thinking about.)

[jhendrixMSFT]

Given that /services has moved to maintenance mode and is superseded by our new, module-based SDKs, I don't think it's worth making this change to the legacy SDK.