Advise about using go mod retract to fix pre go mod v2.0.0 tag

[Steven Hartland]

One of the golang packages I maintain redigo had a v2.0.0 tag created before the introduction of go mod and this still causes challenges today.

A kind soul pointed out go mod retract the other day in the hope that this could help solve the problem. From what I've read it does seem like this is the case and that creating a v2.0.1 tag which includes

retract (
    v2.0.0 // Published accidentally.
    v2.0.1 // Contains retractions only.
)

To be clear the go mod compatible structure of v2.0.0 was never created hence v2.0.0 is listed as incompatible e.g.

go list -m -versions

github.com/gomodule/redigo v0.0.0-do-not-use 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 v2.0.0+incompatible

 

This could help but my concern is if this doesn't work it could make matters worse, so wanted to see if anyone could advise on this process?

   Regards

   Steve

[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 to fix this; the latest version of the "github.com/gomodule/redigo" module will be checked for retractions, and that would be in the v1 series (no v# in the URL, so must be v0 or v1).

[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 Jay or someone else could clarify the v2.0.0+incompatible case?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d7715c26-8b96-4b35-a069-5d638ba2d6a4n%40googlegroups.com.

[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 as a v0 or v1; they have the same name. The "real" v2 would be "github.com/gomodule/redigo/v2", which you can only get from a "real" v2 tag, not any pre-modules tag (which require that there is no "/v2" suffix, for compatibility with old code).

Therefore, the Go toolchain will go look at whatever is latest for "github.com/gomodule/redigo", then use the retractions there. It won't look for "github.com/gomodule/redigo/v2".

[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

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/98df8e56-d897-41fd-b884-44d65ad4760fn%40googlegroups.com.