This looks incredibly brittle. What if one of those dependencies releases a new major version on its master branch that breaks compatibility? You are not suppo

This looks incredibly brittle. What if one of those dependencies releases a new major version on its master branch that breaks compatibility? You are not supposed to do this in Go. If you make changes that are API-incompatible, you need to create a new import path. From the Go FAQ: Packages intended for public use should try to maintain backwards compatibility as they evolve. The Go 1 compatibility guidelines are a good reference here: don't remove exported names, encourage tagged composite literals, and so on. If different functionality is required, add a new name instead of changing an old one. If a complete break is required, create a new package with a new import path. https://golang.org/doc/faq#get_version https://golang.org/doc/faq#get_version Whether this is a good approach is the question, but pushing API compatibilities to an existing import path is considered to be bad. (Since creating a new repository for each API-breaking version is annoying, there are sites such as http://gopkg.in/ http://gopkg.in/ that allow you to expose version branches as a different import paths.)