Closed goto1134 closed 4 months ago
Thank you for the detailed report and the suggestion and for making the repo. I tried to reproduce the issue and to me the issue seems resolved by the retract directive we currently have:
$ go mod init example.com/foo
$ go get github.com/exoscale/egoscale@v0.100.1
go list -m -u -json all
...
{
"Path": "github.com/exoscale/egoscale",
"Version": "v0.100.1",
"Time": "2023-04-26T09:05:59Z",
"Update": {
"Path": "github.com/exoscale/egoscale",
"Version": "v0.102.3",
"Time": "2024-01-15T15:22:50Z"
},
"Indirect": true,
"GoVersion": "1.17"
}
...
So the retracted version doesn't show up in the Update to v0.100.1 anymore. Same for the repo you shared.
@sauterp The issue is not solved.
An example of an effective retractation on the goproxy: https://pkg.go.dev/github.com/traefik/genconf?tab=versions
As you can see the v1.19.0
is not effectively retracted:
You should add:
retract (
v1.19.1 // Retracts the previous version
v1.19.0 // Published accidentally.
)
and create a tag v1.19.1
on the commit that contains the retraction of v1.19.1
.
https://go.dev/ref/mod#go-mod-file-retract
To reproduce the problem:
$ docker run --rm -it golang:1.22-alpine sh
/go # mkdir /foo && cd /foo
/foo # go mod init example.com/foo
go: creating new go.mod: module example.com/foo
/foo # go env GOPROXY
https://proxy.golang.org,direct
/foo # go get github.com/exoscale/egoscale@v0.100.1
...
/foo # go list -m -u -json github.com/exoscale/egoscale
{
"Path": "github.com/exoscale/egoscale",
"Version": "v0.100.1",
"Time": "2023-04-26T09:05:59Z",
"Update": {
"Path": "github.com/exoscale/egoscale",
"Version": "v1.19.0", // <----------------------
"Time": "2019-10-29T14:31:27Z"
},
"Indirect": true,
"Dir": "/go/pkg/mod/github.com/exoscale/egoscale@v0.100.1",
"GoMod": "/go/pkg/mod/cache/download/github.com/exoscale/egoscale/@v/v0.100.1.mod",
"GoVersion": "1.17"
}
/foo # go list -m -u -json all | grep -C 2 github.com/exoscale/egoscale
}
{
"Path": "github.com/exoscale/egoscale",
"Version": "v0.100.1",
"Time": "2023-04-26T09:05:59Z",
"Update": {
"Path": "github.com/exoscale/egoscale",
"Version": "v1.19.0", // <----------------------
"Time": "2019-10-29T14:31:27Z"
},
"Indirect": true,
"Dir": "/go/pkg/mod/github.com/exoscale/egoscale@v0.100.1",
"GoMod": "/go/pkg/mod/cache/download/github.com/exoscale/egoscale/@v/v0.100.1.mod",
"GoVersion": "1.17"
}
/foo #
I created PR #626 to update the go.mod
, you should merge this PR and create a tag v1.19.1
on the commit that contains the retraction of v1.19.1
(the PR content).
Thank you @ldez for the details, your PR is merged and appreciated. I also created the tag. What I still don't understand, is why the issue only reproduces in docker and why it's only visible on go.dev.
Anyway, I'll close this issue once the cache and go.dev are updated.
What I still don't understand, is why the issue only reproduces in docker and why it's only visible on go.dev.
Because you are not using the goproxy or you have an internal goproxy without this version.
FYI, I reproduced the problem locally, I provided an example with Docker just because it's the easier way to be sure of the env.
$ go env GOPROXY
https://proxy.golang.org,direct
I recommend editing the GitHub release of v0.102.3
to flag it as latest
instead of v1.19.1
.
I edited v0.102.3
to be the latest version now. This should be all fixed not thanks to the help of @goto1134 @ldez !
I checked
go env GOPROXY
https://proxy.golang.org,direct
before trying to reproduce it locally, so I'm still wondering why it didn't work for me... But that's just my curiosity. This is done.
The issue is inspired by a bug report to GoLand: https://youtrack.jetbrains.com/issue/GO-15168
go list -m -u -json all
You will see the following output:
Instead I expected:
The issue
As the documentation states,
The current latest version of the module (
v1.19.0
) does not have a retract directive. Please release the higher version of the module (v1.19.1
) containing two retraction directives:P.S. In case of any further retractions, you will have to release a higher version of the module (e.g.
v1.19.2
and so on). Therefore, I suggest releasing a stable module version higher than v1.19.0 and continue the development from that version on.