Re:Google Open Source Load Balancer in Go
by danieldk on Sunday January 31, 2016 @07:49AM
(#11006235)
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.
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/ that allow you to expose version branches as a different import paths.)
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
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/ that allow you to expose version branches as a different import paths.)