Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider retract for v2 lineage #585

Closed
nelz9999 opened this issue Dec 1, 2021 · 9 comments · Fixed by #590
Closed

Consider retract for v2 lineage #585

nelz9999 opened this issue Dec 1, 2021 · 9 comments · Fixed by #590

Comments

@nelz9999
Copy link

nelz9999 commented Dec 1, 2021

As of Go 1.16, there is now a retract directive in the module system.

From my quick-ish reading of things (https://go.dev/ref/mod#go-mod-file-retract), it seems that maybe the way to make end-users' lives a little easier is to publish a v2.0.1 with something like the following in the go.mod file:

retract (
    v2.0.0 // Published accidentally.
    v2.0.1 // Contains retractions only.
)
@nelz9999
Copy link
Author

nelz9999 commented Dec 1, 2021

May solve some of this issues as mentioned on #440 ?

@stevenh
Copy link
Collaborator

stevenh commented Dec 1, 2021

Interesting, as v2.0.0 was never published via gomod it's still flagged as incompatible so shouldn't be considered.

If we did a v2.0.1 I would be concerned it would make the problem worse.

Is this something you have experience with @nelz9999 ?

@nelz9999
Copy link
Author

nelz9999 commented Dec 1, 2021

Sorry to say that I don't have direct experience with this. 😢

But I know that this project fields requests in this realm fairly frequently, so I thought I'd mention the new directive in case it might help.

@stevenh
Copy link
Collaborator

stevenh commented Dec 2, 2021

Thanks I’ll ask on go nuts to see if this would solve the issue

stevenh added a commit that referenced this issue Dec 31, 2021
Retract unpublished versions from go tooling.

Fixes #585
@stevenh
Copy link
Collaborator

stevenh commented Dec 31, 2021

@nelz9999 what do you recon to merging #590 and tagging it v1.8.7?

It's not 100% clear if that will work, might need a v2.0.1, but I don't think it will do any harm?

@nelz9999
Copy link
Author

nelz9999 commented Jan 4, 2022

@stevenh It might be worth a shot... It seems like it could be a low-risk experiment.

But my reading of the documentation has me thinking that you have to roll forward to retract behind you.

@nelz9999
Copy link
Author

nelz9999 commented Jan 4, 2022

The new version must be higher than other release or pre-release versions; that is, the @latest version query should resolve to the new version before retractions are considered.

@stevenh
Copy link
Collaborator

stevenh commented Jan 4, 2022

So sounds like I need to tag v2.0.1 which can be incompatible.

stevenh added a commit that referenced this issue Jan 4, 2022
Retract unpublished versions from go tooling.
Bump go version to 1.16 required for retract statement.

Fixes #585
@stevenh
Copy link
Collaborator

stevenh commented Jan 4, 2022

Feedback on gonuts indicated that was only needed for compatible versions as they are contained in different paths.

Given that I just tried with v1.8.7 and it seems to have worked, with the output from go list -m -versions github.com/gomodule/redigo reporting correctly:

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

So fingers crossed this works for all, thanks for raising the issue which lead to this :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants