cmd/gorelease: fix handling of circular module dependency When inferring a release version, gorelease currently defines a versioned replace directive in the temporary go.mod created for analysis. If the module being analyzed has an indirect dependency on itself the replace directive is not matched by the version selected during MVS, resulting in the analysis being performed against the indirect dependency version rather than the current branch. Fixes golang/go#80497 Change-Id: I8fa0a99272f1b63b6e06af68537c54edba4c285d Reviewed-on: https://go-review.googlesource.com/c/exp/+/806400 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Sean Liao <sean@liao.dev> Reviewed-by: David Chase <drchase@google.com>
This subrepository holds experimental and deprecated (in the old directory) packages.
The idea for this subrepository originated as the pkg/exp directory of the main repository, but its presence there made it unavailable to users of the binary downloads of the Go installation. The subrepository has therefore been created to make it possible to go get these packages.
Warning: Packages here are experimental and unreliable. Some may one day be promoted to the main repository or other subrepository, or they may be modified arbitrarily or even disappear altogether.
In short, code in this subrepository is not subject to the Go 1 compatibility promise. (No subrepo is, but the promise is even more likely to be violated by go.exp than the others.)
Caveat emptor.