[chii]

What i'd want is a way to revert back, if the user sees a problem.

The automatic updating toolchain is not a bad idea, and in most cases it works great. Once in a while though, there's a fuck up and breaks your build or something changes that you didnt expect.

The best way forward is to keep the old tool in a backup location, and have the user be able to revert the update with a single command. Then the user is able to safely return to the old one when the inevitable breakage happens. You could even opt-in to analytics for this action, and the owner of the tool would know if a particular update is a screwup (aka, many people reverted it).

[agwa]

To be clear, the new toolchain doesn't replace the old toolchain, but is installed alongside it, and is only used for modules that explicitly request the newer toolchain in their go.mod file.

[kokada]

Author here.

I think you misundertood how this feature works.

If you have a `go.mod` that sets a `go` directive with a version bigger than the version your Go toolchain is currently running, it will download the binary automatically and pass the commands to the new binary. However this doesn't replace your `go` binary in say, PATH, the new toolchain will be downloaded at `GOPATH`, the same as it does with your modules. This is why there is nothing to backup here, nothing is deleted.

Also, keep in mind that if Go is downloading a new toolchain, it means your project will not work with the current toolchain: because if you set `go 1.23` in your `go.mod`, and your current `go` is version 1.22, it would fail regardless until you either fix your `go.mod` or upgrade your `go` toolchain. What Go is doing here is the later, automatically for you.

[trimethylpurine]

If you didn't commit the breaking change to the repo, couldn't you just revert your local changes? Trashing the mod and sum file and running "tidy" should take care of the rest, I would think. Maybe I'm missing something?