go.mod: use version suffix appropriate for tag

[peterbourgon]

If your repo has a tag that Go modules parses as semver (like v2.11.1) then the module name in the corresponding go.mod must meet Go modules' expectations, specifically if it is v2 or above it must include a /vN version suffix. If you don't do this, your project is essentially unusable by consumers.

The fix I've made to go.mod here is simple, but this isn't the end: you also need to update all your import paths to use the /v2 suffix as well.

Fixes #2602

Checklist:

• Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this is a chore.
• The title of the PR is (a) conventional, (b) states what changed, and (c) suffixes the related issues number. E.g. "fix(controller): Updates such and such. Fixes #1234".
• My organization is added to USERS.md.
• I've signed the CLA.
• I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
• My builds are green. Try syncing with master if they are not.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[alexec]

Can you please look at the failing jobs and fix?

[cameracker]

@peterbourgon doesn't this require a bump to v3? otherwise one would run into the problem where v2 resolves to different versions depending on the package manager

[peterbourgon]

@alexec

Can you please look at the failing jobs and fix?

Sorry, beyond my scope — my intent here is just to show you what needs to happen for the repo to be valid.

—

@CameronAckermanSEL

@peterbourgon doesn't this require a bump to v3? otherwise one would run into the problem where v2 resolves to different versions depending on the package manager

I don't think so — if you have a go.mod you're a Go module, and if you're a Go module you shouldn't be using anything other than Go modules to manage your dependencies. But maybe you're referring to something else?

[cameracker]

@peterbourgon, this is a fair point, but because this fundamentally changes how others should be consuming this library, it is a breaking change in that respect. It really impacts users importing this library indirectly because depending on the way a library imports this one, it may resolve to inconsistent versions. If I'm understanding the test failures correctly, that problem may already be happening.

gofrs/uuid#61

[peterbourgon]

Hmm, that's not a breaking change in the semver sense, but sure, happy to bump to v3. I'm also making an attempt at the other necessary changes, commit(s) incoming...

[cameracker]

FWIW I agree with you that this is not traditionally a semver change.

[peterbourgon]

Replaced by #4197