Go packages have no versions, if you make breaking changes you should make a new package so you don't need to specify a version in some metafile to stop the build process from breaking.
Why would you freeze it? I understand that even with the Go policy on versions it can happen that a change on some external package can cause problems, but that's unlikely to happen and as you have the packages as git repos you can just git reset it back to a commit when it was stable or even better: fix the problem and contribute back.
Why does Java have Maven, Haskell have Cabal, or Python have pip? So you can grab some old code written by someone no longer at a company, build it, fix bugs, and complete your task in a reasonable amount of time.
Without version constraints it's much harder to even say "I can build this program" much less "I can fix this bug".
> that's unlikely to happen and as you have the packages as git repos you can just git reset it back to a commit when it was stable
You seem to be assuming you are the one who wrote the code. I'm more speaking in cases where someone you don't know and can't contact wrote the code. Have you ever had to reverse engineer a very large dependency chain? It is absolutely no fun :/
