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.
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.