Release tags with metadata cannot be indexed by the go module index

[srdtrk]

Summary of Bug

The go module index does not index release tags with metadata. This means that all releases with metadata (with +) are not indexed and therefore are inaccessible to users. The only way to use these releases are through github commits. This means all callbacks and 08-wasm release tags are not indexed by go.

Description

1. Go module indexer does not index tags with metadata according to cmd/go: module commands fail to resolve version tags that include metadata golang/go#26605 (comment).
2. Moreover, if a go user attempts to import a version string with metadata using go get module@v0.1.0+meta, then the go client ignores the +meta and interprets the command as go get module@v0.1.0. (This is not very relevant to our issue but worth mentioning)

This means that none of our release tags for 08-wasm and callbacks middleware have been published. You can see that none of the releases are available for the callbacks middleware in here. And you can see that the only available version of 08-wasm is v0.1.1-ibc-go-v7.3-wasmvm-v1.5 in here. This is available because of a typo by @crodriguezvega which omits metadata by omitting + (this was later corrected, but the correction was not indexed). However, the actual releases of 08-wasm are missing.

Currently, osmosis and some other chains are importing the 08-wasm module through a typo release! And Confio is importing the callbacks module through github commits.

Expected Behavior

Expected behavior is unattainable. We need to come up with a new versioning strategy that doesn't involve metadata.

Version

• 08-wasm v0.1.1+ibc-go-v7.3-wasmvm-v1.5
• 08-wasm v0.1.0+ibc-go-v8.0-wasmvm-v1.5
• 08-wasm v0.1.0+ibc-go-v7.3-wasmvm-v1.5
• callbacks v0.2.0+ibc-go-v8.0
• callbacks v0.1.0+ibc-go-v7.3

Steps to Reproduce

Try to import callbacks or 08-wasm using the release tags.

Tasks

• Add version matrix to our readme files #6337

---

For Admin Use

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

[colin-axner]

Followup question from our discussion: When would we like to move 08-wasm to v1 and greater?

[srdtrk]

We still haven't reached a final decision after today's engineering call. However, we did come up with some options for both long-term and short-term solutions:

Decision:

• Short-term: Create a version matrix similar to the one in the cosmos-sdk for each go.mod in the repo. This matrix will contain the git commit hashes of the Go modules corresponding to their releases. We will continue tagging releases with metadata.

Long term Options:

• Option 1: Ensure that wasmvm upgrades for 08-wasm are not API-breaking and remove it from the metadata.
• Option 2: Treat ibc-go versions as pre-releases and mark tags accordingly. For example: v0.1.0-ibc-go-v7.3. This means we will stop including wasmvm metadata for 08-wasm.
• Option 3: Tag our modules with vX.Y.Z and maintain a version matrix.
  • Increment X for API-breaking changes and/or major ibc-go version bumps.
  • Increment Y for state machine-breaking changes (e.g., a wasmvm bump).
  • Increment Z for patch releases.