Excellent, thanks!

I remember reading http://golang.org/cmd/go/ (specifically, the part about the <meta> tag) a while back and thinking "well, that'd be pretty straightforward to get working" and then (sadly) never having the time for it :(.

I hadn't seen this but it seems like a really elegant solution compared to the alternatives. I look forward to trying it.

That looks nice. Does it work with import statements though or is it only for go get?

It has to work with import statements---that's the whole point. :-)

Thanks for the link. Just tried it out, nice, and I love the use of semver. So you can do this to import a specific version of say yaml

    import "gopkg.in/v1/yaml"

or for an arbitrary url on github

    https://gopkg.in/username/v1.0.0/pkg

Weird that versions are before the pkg name though, that doesn't seem right...

Here's hoping this sort of versioning scheme makes it into the go toolchain eventually. The only downside of this solution is it redirects only to github and guesses urls, I quite like that the go toolchain is indifferent as to where the sources are hosted. This would be very easy to add to the toolchain though; all they'd need to do is recognise imports like this (personally I prefer versions at the end of current urls, not in the middle):

   import "bitbucket.org/user/pkg/v1.1.2"

in go get and download that tag to that path, no other changes in the toolchain would be required, and those who ignore versions could continue to do so, while people who wanted them use the version specific imports. I think the objection of the go team was that this doesn't solve any of the complex dependency issues that plague package managers, but it'd be nice just to be able to specify which version is expected for future users and have predictable builds when sharing code outside one org.

I actually haven't even used gopkg.in myself. Gustavo Niemeyer just released it and has been pushing it as one way to promote API stability. I agree with him and plan to migrate to the scheme soon, as there are a few people using my libraries.

With that said, I doubt very much it will make it into the official toolchain. There's really no point if it can be offered just as well by a third party. For example, godoc.org has proved invaluable but isn't official.

Also, keep in mind that gopkg.in is still pretty new, and I believe Gustavo has said that adding support for other web sites or revision control systems is perfectly doable. Just wanted to get something started for the lowest common denominator, I suspect. :-)

The advantage of having it in go get would be that no one has to rely on a single point of failure like gopkg.in, nor would they have to get new urls recognised there, and finally that it could become an accepted way to version dependencies instead of the versionless future golang lives in right now. They did add versioning to the lang after a while so hopefully this will be similar. It's not a huge deal anyway right now, it'll become more important as the pkg universe grows.