The way I do it in VS Code is to do something like this from the repo root:
# Get the dev version of Go into PATH for the editor and local dev work
$ export PATH=$PWD/bin:$PATH
# Build a baseline version of go and save it to restore if things break, or
for comparison
$ (cd src; GOGC=off ./make.ba
u
>> will *also* need to retract version v1.0.1.
>
>
> I wonder if Jay or someone else could clarify the v2.0.0+incompatible case?
>
> On Mon, 6 Dec 2021 at 06:21, Zik Aeroh wrote:
>
>> Unless I'm mistaken, you should be retracting "v2.0.0+incompatible"
Unless I'm mistaken, you should be retracting "v2.0.0+incompatible", as
that's the actual version known to the Go tool. Retracting "v2.0.0" would
be valid if you were retracting in the "github.com/gomodule/redigo/v2"
module, which it sounds like you aren't.
You wouldn't want to publish v2.0.1 t
All replaces are disallowed when using "go install" with a version number,
regardless of what kind they are; see
https://github.com/golang/go/issues/40276, specifically the sections about
"replace".
I have a tool I'm currently rewriting that manages $GOBIN via a config
file; I'm relying on "go
