Preparing a v2.0.2+incompatible pre-release to properly retract v2.0.1+incompatible

[AnomalRoil]

We need to issue a higher version tag which self-retract itself in order to retract v2.0.1+incompatible
I have chosen a pre-release v2.0.2+incompatible value so that it will still be possible to create v2.0.x versions in the future without conflicting with it.

After merging this, please tag the latest master with tag v2.0.2+incompatible and push the tag to github 🙏🏻

As per the Go spec:

To retract a version, a module author should add a retract directive to go.mod, then publish a new version containing that directive. The new version must be higher than other release or pre-release versions; that is, the @latest version query should resolve to the new version before retractions are considered
A version containing retractions may retract itself. If the highest release or pre-release version of a module retracts itself, the @latest query resolves to a lower version after retracted versions are excluded.

[welcome]

Thank you for submitting this PR!
A maintainer will be here shortly to review it.
We are super grateful, but we are also overloaded! Help us by making sure that:

• The context for this PR is clear, with relevant discussion, decisions
  and stakeholders linked/mentioned.

• Your contribution itself is clear (code comments, self-review for the
  rest) and in its best form. Follow the code contribution
  guidelines
  if they apply.

Getting other community members to do a review would be great help too on complex PRs (you can ask in the chats/forums). If you are unsure about something, just leave us a comment.
Next steps:

• A maintainer will triage and assign priority to this PR, commenting on
  any missing things and potentially assigning a reviewer for high
  priority items.

• The PR gets reviews, discussed and approvals as needed.

• The PR is merged by maintainers when it has been approved and comments addressed.

We currently aim to provide initial feedback/triaging within two business days. Please keep an eye on any labelling actions, as these will indicate priorities and status of your contribution.
We are very grateful for your contribution!

[aschmahmann]

CI is failing with: go.mod:28: retract github.com/ipfs/go-ipfs-cmds: version "v2.0.2-retract" invalid: should be v0 or v1, not v2

It looks like this might be because we'd need to change the import path in this go mod file as well golang/go#35732 (comment). I haven't dealt with two many v2 modules like this before though so lmk if I'm missing something.

[aschmahmann]

Side note: Does this need to merge into master or can this merge into a v2.0.2-retract-branch and be released from there?

[AnomalRoil]

I think this sadly has to stay in the go.mod for subsequent releases and cannot just be removed after tagging the higher v2.0.2-retract self-retracting pre-release, but not 100% sure.

[lidel]

Triage notes:

• @AnomalRoil where does this problem manifest?
• gx tags were created before modern v2 conventions were introduced and it may be tricky to fix, so we want to understand the priority here (creating dead v2 version only to solve low priority problem does not sound like a good play)

[AnomalRoil]

Currently the Go ecosystems recognizes the v2.0.1+incompatible to be the latest release:

To properly retract a release you need to tag a higher version number tag with a retract statement for both.

See doc here: https://go.dev/ref/mod#go-mod-file-retract

The main goal being to allow people to use go get -u to update dependencies successfully, but tbh I'm not even sure the latest issue is related to this one:

$ go get github.com/ipfs/go-ipfs-cmds@latest
go: github.com/ipfs/go-ipfs-cmds imports
	github.com/ipfs/go-ipfs-cmdkit/files: cannot find module providing package github.com/ipfs/go-ipfs-cmdkit/files

[lidel]

Triage notes:

• Using https://go.dev/ref/mod#incompatible-versions should make this relatively safe in module version ecosystem, we will give it a try.

[lidel]

Just for the record (cc @gammazero) this did not work because +incompatible is respected only if tag does not include go.mod:

$ GOPROXY=https://proxy.golang.org GO111MODULE=on go get "github.com/ipfs/go-ipfs-cmds@v2.0.2"
go: github.com/ipfs/go-ipfs-cmds@v2.0.2: reading https://proxy.golang.org/github.com/ipfs/go-ipfs-cmds/@v/v2.0.2.info: 404 Not Found
	server response: not found: github.com/ipfs/go-ipfs-cmds@v2.0.2: invalid version: module contains a go.mod file, so module path must match major version ("github.com/ipfs/go-ipfs-cmds/v2")

I've removed the tag since it is useless anyway and filled golang/go#69093 to remove broken version from x/pkgsite.

@AnomalRoil until upstream is cleaned up, as a workaround, you can run GOPROXY=direct GO111MODULE=on go get -u ./... to skip broken cache of x/pkgsite.

[AnomalRoil]

@lidel I suspect this did not work properly because you tagged v1.13 instead of tagging v2.0.2+incompatible and v1.13 < v2.0.2+incompatible as per semver.

Edit: reading the other issue, it seems that should work if we tagged v1.0.23 instead of v2.0.2+incompatible.
Meaning we need to retract v1.0.23 in the go.mod and tag it.