Repository has been renamed

The retract directive is designed to work with GitHub redirects. You should be able to add a retract directive in the go.mod file at the new location retracting the range of versions that were published for the old path.

And I notice that you did attempt to do that. It is possible that your repo has run into #61415, which may prevent the proxy from fetching it going forward.

@suzmue, is it possible to remove the proxy's cached origin data for this module path?

You should be able to add a retract directive in the go.mod file at the new location retracting the range of versions that were published for the old path.

How would that work if the old module had v1.0.0 and the new starts at v1.0.0 - means I would have to add the retract directive to the new repository, publish a higher version, remove the directive and publish a higher version?

At the moment when going on the new module URL with the @ version indicator, it redirects to the old URL with a "retracted" notice at the top.

If the two module paths share the same repository location, they cannot also share a given version number.

If you want to be able to restart at v1.0.0, I would suggest leaving the old repo in place at the old path and creating a new repository (perhaps a fork of the repository with all prior version tags removed?) at the new path.

Both modules are separated at the moment in different repositories. One tagged version v1.6.0 - on pkg.go.dev it's on v1.5.1 and marked as retracted (which I want to be entirely removed) and the new one tagged v1.0.1 which I want to not redirect to the old one which it currently does.

Due to the security properties of the checksum database, the contents of the version for a given repo path cannot be changed once it has been fetched and checksummed.

https://proxy.golang.org/cached-only/github.com/kkrypt0nn/acrux/@v/v1.5.1.info unfortunately shows that the proxy has already processed v1.5.1 for that path, so the remaining options at this point are to pick up at v1.6.0 or so (instead of v1.0.0), to retract the old versions pointwise and use the next patch number after the old version (`v1.0.2, v1.1.2, v1.2.1, etc.), or to abandon that repo path and start fresh with an entirely new one.

So I could make a new tag v2.0.0 for acrux and it would be just fine?

Yep! But you'd also need a /v2 import path to match it: module github.com/kkrypt0nn/acrux/v2.

That sounds amazing, I can live with the v2! Will do that tomorrow :)