It appears that someone moved or otherwise changed the tags in that repository.
Using a go command installed from https://golang.org/dl, I see:

$ export GOPROXY=direct

$ go1.16.4 get -d github.com/redhat-developer/app-services-sdk-go@v0.1.0
go: downloading github.com/redhat-developer/app-services-sdk-go v0.1.0
go get: github.com/redhat-developer/app-services-sdk-go@v0.1.0: verifying module: checksum mismatch
        downloaded: h1:CTtOQF56Byqzif+XOwD877tjSQygBxs3C/S4s5k/RX8=
        sum.golang.org: h1:HmEhUCF4ohSOghuC9YmYgx7QS4nMkRABmsbEcgx4zuA=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

$ go1.16.4 get -d github.com/redhat-developer/app-services-sdk-go@v0.1.1
go: downloading github.com/redhat-developer/app-services-sdk-go v0.1.1
go get: github.com/redhat-developer/app-services-sdk-go@v0.1.1: verifying module: checksum mismatch
        downloaded: h1:+2GtV3ouUy+Cnls+JZPRkk5Hlo9mUgQ+goXdInElyrM=
        sum.golang.org: h1:wa0XmeJ/5zS/rftq8N7UZyjQHgT1laAA/xXH99rtOC8=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

That suggests to me that whoever is using that repo is probably bypassing both the Go module proxy (https://proxy.golang.org) and the Go checksum server (https://sum.golang.org). Requests to the proxy and/or checksum server are what cause packages to be included in the index (https://index.golang.org), and the index is how pkg.go.dev finds out about new versions — if nobody tells the Go servers about new versions, then (by design!) they won't be indexed on pkg.go.dev.

I seem to recall that the Fedora fork of the go command intentionally bypasses the Go servers by default. Is it possible that the developers and users of github.com/redhat-developer are using the Fedora fork instead of an unmodified distribution of the Go toolchain and forgetting to enable the proxy and checksum server?

To avoid these kinds of problems, I recommend that you use Go binaries distributed and supported by the Go project (or built from unmodified source) to develop your module.

Regarding v0.1.2 specifically, we don't show it because it contains no Go code. It looks like you've moved all the packages into sub-modules. That's fine, but it means there's nothing for us to show. (We have to ignore module zips with no Go files, because nothing else in the pipeline does any checking. For example, the module proxy can (and probably does) contain zips of pure Javascript or Python or whatever.)

You could add a doc.go file to the top-level module that contains some documentation. That trivial package should be enough for us to display a page, with links to the sub-modules in the Directories section. Your doc.go file could hold information common to all the project's packages. For a similar case, see https://pkg.go.dev/cloud.google.com/go@v0.82.0#section-documentation, although that top-level module does have some other packages in it.

It appears that someone moved or otherwise changed the tags in that repository.
Using a go command installed from golang.org/dl, I see:

$ export GOPROXY=direct

$ go1.16.4 get -d github.com/redhat-developer/app-services-sdk-go@v0.1.0
go: downloading github.com/redhat-developer/app-services-sdk-go v0.1.0
go get: github.com/redhat-developer/app-services-sdk-go@v0.1.0: verifying module: checksum mismatch
        downloaded: h1:CTtOQF56Byqzif+XOwD877tjSQygBxs3C/S4s5k/RX8=
        sum.golang.org: h1:HmEhUCF4ohSOghuC9YmYgx7QS4nMkRABmsbEcgx4zuA=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

$ go1.16.4 get -d github.com/redhat-developer/app-services-sdk-go@v0.1.1
go: downloading github.com/redhat-developer/app-services-sdk-go v0.1.1
go get: github.com/redhat-developer/app-services-sdk-go@v0.1.1: verifying module: checksum mismatch
        downloaded: h1:+2GtV3ouUy+Cnls+JZPRkk5Hlo9mUgQ+goXdInElyrM=
        sum.golang.org: h1:wa0XmeJ/5zS/rftq8N7UZyjQHgT1laAA/xXH99rtOC8=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

That suggests to me that whoever is using that repo is probably bypassing both the Go module proxy (proxy.golang.org) and the Go checksum server (sum.golang.org). Requests to the proxy and/or checksum server are what cause packages to be included in the index (index.golang.org), and the index is how pkg.go.dev finds out about new versions — if nobody tells the Go servers about new versions, then (by design!) they won't be indexed on pkg.go.dev.

I seem to recall that the Fedora fork of the go command intentionally bypasses the Go servers by default. Is it possible that the developers and users of github.com/redhat-developer are using the Fedora fork instead of an unmodified distribution of the Go toolchain and forgetting to enable the proxy and checksum server?

To avoid these kinds of problems, I recommend that you use Go binaries distributed and supported by the Go project (or built from unmodified source) to develop your module.

Thanks for the info - I was using the Fedora fork and have changed it now!

Regarding v0.1.2 specifically, we don't show it because it contains no Go code. It looks like you've moved all the packages into sub-modules. That's fine, but it means there's nothing for us to show. (We have to ignore module zips with no Go files, because nothing else in the pipeline does any checking. For example, the module proxy can (and probably does) contain zips of pure Javascript or Python or whatever.)

You could add a doc.go file to the top-level module that contains some documentation. That trivial package should be enough for us to display a page, with links to the sub-modules in the Directories section. Your doc.go file could hold information common to all the project's packages. For a similar case, see pkg.go.dev/cloud.google.com/go@v0.82.0#section-documentation, although that top-level module does have some other packages in it.

Thanks! That makes sense.

It doesn't seem like there's anything actionable on our end, so closing this issue.