@jadekler and I spent some time talking today about the future of gorelease. Here's what we're thinking.

• There seem to be two diverging use cases: 1) checking whether the module in the current directory is ready to be released as a new version, and 2) find what changed between two existing versions, either of the same module, different major versions, or different modules (forks, renames). The code that serves these use cases in nearly the same, but we should think about splitting the CLI.
• We eventually want to make gorelease part of the go command. Like go doc, it will run a separate binary (cmd/doc in that case). As part of this, I propose we name the command go mod vet to make it clear this is module-related, and it analyzes something like go vet. The name go release makes it sound like it's performing a release (uploading something), and the GoReleaser project has a similar name.
• Comparing APIs of existing versions doesn't seem like it should be part of go mod vet, though it's an important use case. We should move this into a new command, say golang.org/x/tools/cmd/gomoddiff.

To move forward, let's do the following:

• Confirm via proposal process in cmd/go: add 'go release' #26420 or a new issue that this is the right approach forward.
• Fix release blocking bugs and add core features:
  • x/exp/cmd/gorelease: gets stuck in "Run go mod tidy" loop with cyclic module dependencies #44133
  • x/exp/cmd/gorelease: allow major version comparisons #40913
  • x/exp/cmd/gorelease: accept any release version when inferring base version of untagged repo #40267
  • x/exp/cmd/gorelease: report requirements on retracted module versions #37781
  • x/exp/cmd/gorelease: positional arguments should specify packages to compare #37566
  • x/exp/cmd/gorelease: support -json and -f flags #37561
  • x/exp/cmd/gorelease: report when packages can't be loaded without replace, exclude #37559
  • x/exp/cmd/gorelease: decide on report and diagnostic format #46372
  • See the gorelease milestone for a complete list of issues; issues not included in the list above probably shouldn't block go mod vet.
• Refactor most of the core code into a library in x/tools that can be used to implement go mod vet and gomoddiff.
• Move the CLI into cmd/gomodvet and golang.org/x/tools/cmd/gomoddiff.
• Add go mod vet that invokes cmd/gomodvet.