You can't. You are expected to vendor for dependable builds. This has upsides and downsides.
It does completely sidestep version dependencies hell and encourages you to think carefully about which dependencies you package. It does that by making you manually responsible for keeping dependencies up to date if you distribute other people's code with your own.
So, in answer to your original question, no go doesn't finally have a package manager with proper versioning (at least no official one). In practice, this is not as big an issue as you might think if you come from a language with such a package manager. In practice, I haven't really found it as much of a burden as I thought I might.
Sure it's possible with third party tools (in this case gopkg.in), and if all your required packages support this. As gopkg.in is a centralised service I'm not so keen on that solution (same problems and potential pitfalls as relying on say rubygems.org as a source of truth).
There are multiple ways to solve these problems (vendoring is one, your solution another, godep another path), but the go get tool doesn't explicitly allow for versioning in the way the parent requested and there is no official solution to this.
The point about gopkg.in being centralized is valid. You can run a copy yourself (it's open source), or you can use a more simplistic version that many people use which doesn't even require running a service, just serving some static HTML. This obviously only works for code you're maintaining. However, if you think code you're depending on isn't maintained by people you can trust not to break you, it's probably better to use something like godep to insulate you from them anyway, right?
The official solution to versioning is separate URLs. If you mean something more complicated like automatic resolution of different version specifications (e.g. ver >= 1.2), then no, nothing exists like that. But generally all you need is "project A uses version foo, and project B uses version bar", and Go supports that just fine.
However, if you think code you're depending on isn't maintained by people you can trust not to break you, it's probably better to use something like godep to insulate you from them anyway, right?
That goes for most code at some point in time; as it evolves the behaviour changes in subtle ways. I do think the go team's insistence that packages should never break their API and remain effectively versionless is somewhat utopian.
The official solution to versioning is separate URLs.
I remember reading an off-hand comment from someone on the go team that you could just rename your package, however I don't think that's a very good idea, and this doesn't play nicely with many popular hosts like github. They have support for version tags on repos in go get, but only for golang versions so it is unused, which is a shame. So there's no official tooling for it. At present the majority of go code I've seen simply imports dependencies from github or similar without versioning and hopes for the best. Unless the other pkg author wants to version, that's all you can do unless you want to vendor (for large dependencies like net/html that can be impractical).
If you mean something more complicated like automatic resolution of different version specifications (e.g. ver >= 1.2), then no, nothing exists like that.
That's what the parent was asking for I think, and more than that something which applies to all pkgs. Personally I've chosen to minimise external dependencies, and vendor them in version control. It's simple, and it pus me in control of updating and versioning for code I use, not the package authors.
We're having lots of fun with this with Prometheus, quite a bit of work is ongoing to get it into Debian due to this for example.