gopkg.in prefers 'go1' branch over 'v1.0.9' branch? about gopkg HOT 5 CLOSED

This is beyond the control of gopkg.in, as it's the "go" tool that is switching over the branch content after it acquires it. That said, it's still not clear to me why you'd want that go1 branch. You might even drop the master branch altogether if you wish, and both the git and the go tool workflow would still work fine. In github you may easily modify what is the focus of development at the moment, and everything else (PRs, Issues, etc) will work in terms of it. Another trick you may use is to create a master branch which errors out nicely if imported.

Have a look at https://github.com/go-mgo/mgo for example, to see some of these ideas in use.

from gopkg.

How does gopkg.in tell go get which branch to checkout? Is that by setting the default branch?

We like using master as the dev branch because all our 300+ repos do that. I thought that a go get github.com/... would check out the go1 branch while going via gopkg.in wouldn't so I wanted to break the go1 branch to catch mistakes where someone (like myself...) imports the github version by mistake.

from gopkg.

When you checkout a branch with git, the references in that branch are retrieved as well, so the go tool can trivially switch over to that when it finds the reference available. Also, you can certainly continue to use master as your development target, if that's what you'd like to do inside your GitHub workflow.

We can also disable the go1 tag when going via gopkg.in, as that's clearly getting in the way and doing no good, but for the time being (before that feature is released) I suggest just dropping the tag.

from gopkg.

Understood. BTW, thanks for gopkg.in !!!

from gopkg.

You're welcome, and glad it's being useful there.

from gopkg.