<p>Looking for some advice on how to organize go packages for a client library that I'm working on. The client library needs to support multiple versions of an API, and so my options are:</p>
<ul>
<li>1) different repos for each supported version</li>
<li>2) single repo, different branches for each version (harder to import without going to gopkg.in route)</li>
<li>3) single repo, different packages for each version</li>
</ul>
<p>I'm leaning on #3 only because all of the other language client libraries pack all version support into a single repo, different paths. With go and packaging, I'm a little fuzzy on how to best organize this. Any thoughts?</p>
<hr/>**评论：**<br/><br/>Fwippy: <pre><p>You could also use build tags, so that all of the different API code lives side-by-side in the repo. I'd only use this if the version-specific code is a relatively small portion of the repo, though.</p>
<p>I think this approach also makes it difficult to use with <code>go get</code>.</p></pre>kjk: <pre><p>To me it depends on why you think you need to support multiple versions.</p>
<p>Is it a different API by design, and you want to maintain them in parallel? They belong in different repos because they are different things.</p>
<p>Are you worried that you'll have to change the API over time to fix bugs or design errors in earlier versions? That doesn't happen that often and if it ever does, you don't have to do anything. </p>
<p>People using your library can vendor it and pin an exact version (down to a specific checkin) they use using one of the many tools for that, like godeps.</p>
<p>Every serious project I've worked on was pinning dependencies anyway - you absolutely have to do that for reproducible builds. We were isolated from API changes and bugs that might have been introduced later.</p>
<p>From time to time we would bump the version in which case we would re-test and update the code for new APIs if that was needed (but that comes up very rarely in practice).</p></pre>jbuberel: <pre><p>The last time this was discussed among members of the Go team at Google, the general recommendation was:</p>
<p>Once you've reached v1 for your API, make an explicit compatibility promise. If you need to change the API in a way that breaks that promise, it should happen on a different import path.</p>
<p>Although Fowler recommends against versioning REST API paths:</p>
<pre><code>/myendpoint/v1/functionA
/myendpoint/v2/functionA
</code></pre>
<p>I do think that in the Go case, it is preferred over your options #1 (seems excessive) and #2 (too complex to maintain).</p></pre>
