Re: [go-nuts] Re: Advise about using go mod retract to fix pre go mod v2.0.0 tag

2022-01-04 Thread Steven Hartland
Thanks Zik, looks this worked as go list -m -versions github.com/gomodule/redigo now returns the expected versions: github.com/gomodule/redigo v1.7.0 v1.7.1 v1.7.2 v1.8.0 v1.8.1 v1.8.2 v1.8.3 v1.8.4 v1.8.5 v1.8.6 v1.8.7 On Mon, 3 Jan 2022 at 02:41, Zik Aeroh wrote: > I don't think you need to

Re: [go-nuts] Re: Advise about using go mod retract to fix pre go mod v2.0.0 tag

2022-01-02 Thread Zik Aeroh
I don't think you need to do anything with the "real" v2. The way I visualize this is to think of "v0+v1", "v2", "v3", and so on as completely different modules; they have entirely different names by SIV. The version "v2.0.1+incompatible" would be imported as "github.com/gomodule/redigo", same

Re: [go-nuts] Re: Advise about using go mod retract to fix pre go mod v2.0.0 tag

2021-12-31 Thread Steven Hartland
Thanks Zik, not clear if I still need to publish v2.0.1 to retract v2.0.0+incompatible given the comments in https://play-with-go.dev/retract-module-versions_go116_en/ To retract v1.0.0 you will need to publish v1.0.1. But that means you will > *also* need to retract version v1.0.1. I wonder if

[go-nuts] Re: Advise about using go mod retract to fix pre go mod v2.0.0 tag

2021-12-05 Thread Zik Aeroh
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