It is quite neat and mighty convenient, but I sorta live in fear that at some arbitrary point the library will change and my code will just stop working. I konw this isn't a problem unique to Go and there are solutions, but the lack of explicit versioning makes me nervous. Then again, it hasn't bit me yet, and I certainly have benefitted from the ease.

I think it works out pretty well- if you're working on a Very Serious Project(TM), you point it at a URL that's your project's closely managed fork.

it doesn't "compile from a url", the package name is just the url address. You still have a directory of downloaded packages analogous to Python's site-packages, and they don't update unless you explicitly update them. The difference is that if you say `go get github.com/whatever/foo` the package source will be downloaded to a location such as `/usr/local/go/src/pkg/github.com/whatever/foo`.

One solution is to add version to url. Some examples from Google API for Golang (http://code.google.com/p/google-api-go-client/): code.google.com/p/google-api-go-client/tasks/v1 code.google.com/p/google-api-go-client/books/v1

This is absolutely the only right way to do this. It's very unsettling that locking to a specific revision isn't considered the default.

Depending on git master is cowboy coding at its most cavalier; build systems should prize repeatability above all else.

If you'r really worried about code changes that might break your project, you're free to fork the library, e.g. if it's on GitHub. Even though that's not really a sophisticated way of versioning, it's quite convenient.

There are a few things that can be done:

1. Hope that the projects you depend on have a tag that you can reference as your import or that you can acquire specifically with `go get`

2. Fork them and keep track of them yourself.

3. Use the tool (I can't find the link) that manages version dependencies per-project so that you can have different versions for different projects based on your needs (think virutalenv).