1. Don't import packages that break unreasonably.
2. If that's not an option, fork the package and import your stable fork instead.

I don't have an opinion on this, but I think that you should definitely expand on:

glide/go dep is not an answer to every case .

If you show a concrete example of a situation that cannot be solved by using e.g. dep, but can be solved by adding a --rev flag to go get, you'll minimize the chances of someone just replying "just use dep", like it happened the last time you asked for this. I note that dep allows to force a specific revision field for a dependency.

Arguing that there's no harm in adding an extra flag is not entirely true - once added and released, we're stuck with it in Go1 (and a future Go2 too, potentially). It is also unclear whether Go should be encouraging such practices - for now, it seems to be opinionated against pinning specific versions when simply "getting" a package.

Also worth noting that some replies and alternatives were given in the original thread (#21933), but it was closed without any of them being discussed or argued against.

Edit: I was wrong to assume that the command-line tools fall under the Go1 compatibility guarantee. But even so, removing or changing a flag can still cause problems and inconveniences to users, which should be avoided whenever possible.

dep, as any "file-based" soultion has a problem that if it's not originally in the repo, I get diverging git history the moment I need to fix some version somewhere. I don't see it used by Hashicorp, which is a showstopper for me. I don't see it used much at all, for that matter. Also, go dep is not exactly stable, look at it's issue list.

Being opinionated against having a version is a strange thing for me, to be honest. What good does it bring? If you want "latest code only" behavior, why are branches an option then? Anyway, it's just not clear to many people. If you guys still decide to leave it as it is - at least write some verbose explanation why is this solution chosen so we don't restart the conversation.

Again, I want to bring the point home - one flag is not going to break anything. It will only trigger checkout, there's not much code to maintain there. If it's broken - well, you roll back to current behavior. v1 or v2, it's just a bit of wrapper "sugar".

Closing in favor of the versioning work in #24301.