What is the best practice around pinning external go package versions? Is `gopkg.in` still the default choice?

<p>I heard rumors that there was going to be some type of semantic versioning built into go itself to handle external package references changing over time. Does anyone have a better solution than <code>gopkg.in</code> or is it still the best choice? What about for packages that haven&#39;t defined a &#34;v1.0&#34; tag yet (like, aws/aws-sdk-go, ahem ahem).</p> <hr/>**评论：**<br/><br/>Luett_un_Luett: <pre><p>Go 1.5 has (experimental) support for vendoring.</p> <p>See: <a href="https://golang.org/doc/go1.5">Release Notes</a></p></pre>gdm85: <pre><p>You&#39;d still want to use some tool to manage them. The stages of dependency management usually go as:</p> <ul> <li>add a new dependency, pinning it to a specific version</li> <li>update a dependency</li> <li>remove a dependency</li> </ul> <p>I&#39;ve been using <a href="https://github.com/Masterminds/glide" rel="nofollow">glide</a> although I have mixed feelings about it.</p></pre>Luett_un_Luett: <pre><p>What value does that add over using 1.5-vendoring + plain simple git?</p></pre>gdm85: <pre><p>I assume by &#34;plain simple git&#34; you mean git submodules. For one, the source code might not be available through git or svn, and you might want to version your <em>vendor</em> directory without having to fetch/update it every time you want to build (a repository that contains everything needed to build is the analog of a Go binary that has no dynamic-linked library dependencies). The value added by a tool is that you will not repeat the operation manually for either 1 or 20 dependencies, and you can have all the dependencies declared in a (versioned) manifest. Do I really have to explain this?</p> <p>Examples from other languages/build environments:</p> <ul> <li><a href="https://pypi.python.org/pypi/pip" rel="nofollow">https://pypi.python.org/pypi/pip</a> Python</li> <li><a href="https://www.nuget.org/" rel="nofollow">https://www.nuget.org/</a> C#</li> <li><a href="https://maven.apache.org/" rel="nofollow">https://maven.apache.org/</a> Java</li> <li><a href="https://www.npmjs.com/" rel="nofollow">https://www.npmjs.com/</a> node.js</li> </ul></pre>-Nii-: <pre><p>What&#39;s wrong with glide?</p></pre>pierrrre: <pre><p>godep for me</p></pre>Celestro: <pre><p>I&#39;m moving everything to <a href="http://getgb.io/" rel="nofollow">gb</a> so I don&#39;t have to worry about it. It works wonderfully.</p> <p>If that&#39;s not an option, gopkg.in is great.</p></pre>bmatsuo: <pre><p>I like gb quite a lot. But I dislike how incompatible it is with the rest of the Go ecosystem. It can be difficult to import packages from projects managed by gb.</p> <p>It is also missing important features like cross-compilation and race detector support.</p></pre>kardianos: <pre><p>I&#39;m confused on why you say this. gb enables workspaces and &#34;vendor/src&#34;, but the go tool supports the &#34;vendor&#34; folder as well. Have you tried &#34;govendor&#34;?</p></pre>Celestro: <pre><p>I have not. <code>gb</code> does a wonderful job.</p></pre>gdm85: <pre><p>Where did you hear about such semver feature?</p></pre>