Support for full version or arbitrary references

[cheddar]

I'm not sure if this is philosophically opposed to the gopkg philosophy, but I figured creating an issue was the best way to see if it could be done :).

I am new to Go, but my company is switching from a primarily javascript/Node.js backend to a Go backend.

With package and dependency management systems in other languages (Java, Node), I've had enough bad experiences surrounding automatically pulling in updated code that supposedly follows semantic versioning that I have completely written off any sort of automatic resolution of semantic versioning and, instead, prefer to know exactly which version I am dealing with, always.

This is also required if you want "repeatable builds". Where a "repeatable build" is defined as the output from multiple builds done on different machines (but with the same architecture) should produce the exact same output. If your build system might pull down a different version of a library, then the output can be different.

For these reasons, I'd like to request the ability to specify the full, exact version that I would like to depend on with gopkg.

I can probably help out with a PR if you point me in the right direction for what to adjust.

[niemeyer]

While gopkg.in does support full versions via tags or branches in the repository, you are right that the URL must contain only the major version, and that's a deliberate decision for multiple reasons.

This post covers the issue in detail:

http://blog.labix.org/2015/01/14/no-minor-versions-in-go-import-paths

[cheddar]

@niemeyer

Thanks for the explanation, makes sense. Looks like we'll have to make a decision on godep vs gopkg vs ...

[niemeyer]

Again, there's no godeb vs. gopkg. They solve different problems, and work fine together.