pkg != dep

Go packages do not solve project dependencies. They package source code. What's a project? Who knows, that's your business, not the compiler's.

A package can import some other package, but the compiler only cares if it can compile. It doesn't care about that critical bugfix you sent upstream.

go get will resolve dependant packages, but doesn't consider any notion of versioning. I don't blame it, its a very complex problem. go get does not a dep tool make.

What tool is good for keeping track of versions? git (or cvs, hg, …). From go's FAQ:

… the simplest solution is to copy it to your local repository.

Sounds dirty? It's simple, you can fix it with a hammer.

Jay Leno at Laguna Seca 03

At the end of the day, the goal is to isolate versions of packages. Go resolves imports from within the GOPATH. Vendoring isolates a version of a package to a new unique import path. Alternatives solve this via GOPATH manipulation. GOPATH tricks do work, but they establish new conventions that your tooling may not accomodate. This holds unless the toolchain changes.

Who am I to say what's better for you, but vendoring is simpler: some import paths get slightly longer vs a more fragile tooling situation.

Programming is full of trade-offs, we tend to push them outside our text editors and consider it solved. Sometimes the better solution is in the code.