Go Package Versioning Proposal

<p>Relative noob here but to handle situations where a Go package needs to be versioned, how about this proposal...</p> <ul> <li>Add another optional parameter to the <code>go get</code> command where the user can specify a repo branch. So if I needed version 3 of a package I could get it in this way</li> </ul> <p><code>go get github.com/hepcatcoder/catpackage v3branch</code></p> <ul> <li>likewise add the same optional operand or parameter to the import statement</li> </ul> <p><code>import github.com/hepcatcoder/catpackage v3branch</code></p> <p>The <code>go get</code> command could write a hidden file that contains the branch associated with source: <code>master</code>, <code>v3branch</code>, etc. </p> <p>If an import does not specify a branch then the Go compiler would import the source normally. If an import statement specified a branch that was not reflected in the hidden file then the compiler would throw an import error</p> <p>I don&#39;t have deep knowledge of the current state of versioning in the Go world so my guess there are issues this approach would run into. But thought I&#39;d throw it out to <a href="/r/golang" rel="nofollow">r/golang</a></p> <hr/>**评论：**<br/><br/>ChristophBerger: <pre><p>The current state of Go dependency management (which includes versioning) is <a href="https://github.com/golang/dep" rel="nofollow">here</a>. I think the <code>dep</code> tool already does a decent job around version pinning.</p> <p>Your suggestion seems to be on the same line as <a href="http://labix.org/gopkg.in" rel="nofollow">gopkg.in</a> (only without the need for an extra server), so the concept should have the same pros and cons as gopkg.in. </p> <p>The biggest drawback I see here is that if you have a large project with 20 versioned import statements and you decide to switch to a newer version, then you need to update 20 import statements in 20 files (and make sure not to miss one).</p></pre>adelowo: <pre><p>I was thinking of something similar the other day but a <code>-vendor</code> flag that saves the repo to the vendor directory rather than <code>$GOPATH</code></p> <p>0 - The <code>-v</code> flag is already taken though</p></pre>kron4eg: <pre><p>Just use golang/dep.</p></pre>