Hello!

On your repo, I see that both 1.0.3 and 1.0.4 point to the same commit 43fd3c3, with less than 10 minutes between releasing them and opening your issue, so it might have been an issue with caching? When did you run the above command?

As https://sum.golang.org/ states

new versions may not show up right away. If you want new code to be immediately available in the mirror, then first make sure there is a semantically versioned tag for this revision in the underlying source repository. Then explicitly request that version via go get module@version.

On my end, it seems to be working correctly now

$ mkdir tmpdir
$ cd tmpdir
$ go mod init tmp
go get -u github.com/bukforks/cobra@v1.0.4
go: downloading github.com/bukforks/cobra v1.0.4
go: downloading github.com/inconshreveable/mousetrap v1.0.0
go: downloading github.com/spf13/pflag v1.0.5

Finally, I feel that following the provided template when filling the issue will provide more information that will help understand and resolve the issue in a clearer way in the future!

Hello thanks a lot for your assistance. I just updated the issue to match the template. It is not the first time i have problems with go mod caching. I expected that releasing new package would instantly be available - as it really is.

You're welcome! As https://sum.golang.org/ states, the cache has a quite short TTL, so while not immediate, it should be available very soon.

After one minute for caches to expire, the go command will see that tagged version

You can use go list -m --versions github.com/bukforks/cobra to see the available versions as they're picked up.

Would you like to try and reproduce the behavior? I think that the two tags pointing to the same commit might have something to do with what you observed.

@bcmills

What was your initial go.mod state? This looks superficially similar to #37438 (see #37438 (comment) in particular).

Does the error still reproduce if you run go env -w GOPROXY=direct before the go get command? (Be sure to run go env -u GOPROXY afterward to reset your go command defaults.)

What was your initial go.mod state?

I am pretty sure there was github.com/bukforks/cobra@v1.0.3.

@bukowa, you'll need to provide more specific steps to reproduce. Here's what I'm seeing so far:

example.com$ go version
go version go1.15.1 linux/amd64

example.com$ go mod init example.com
go: creating new go.mod: module example.com

example.com$ go get -d github.com/bukforks/cobra@v1.0.3
go: downloading github.com/bukforks/cobra v1.0.3
go: downloading github.com/inconshreveable/mousetrap v1.0.0
go: downloading github.com/spf13/pflag v1.0.5

example.com$ cat go.mod
module example.com

go 1.15

require github.com/bukforks/cobra v1.0.3 // indirect

example.com$ go get -u github.com/bukforks/cobra@v1.0.4
go: downloading github.com/bukforks/cobra v1.0.4

example.com$ cat go.mod
module example.com

go 1.15

require github.com/bukforks/cobra v1.0.4 // indirect

example.com$ go list -m all
example.com
github.com/bukforks/cobra v1.0.4
github.com/cpuguy83/go-md2man/v2 v2.0.0
github.com/inconshreveable/mousetrap v1.0.0
github.com/pmezard/go-difflib v1.0.0
github.com/russross/blackfriday/v2 v2.0.1
github.com/shurcooL/sanitized_anchor_name v1.0.0
github.com/spf13/pflag v1.0.5
gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405
gopkg.in/yaml.v2 v2.3.0

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)