<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 23, 2014 at 9:52 AM, roger peppe <span dir="ltr"><<a href="mailto:roger.peppe@canonical.com" target="_blank">roger.peppe@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>That's not quite how it works. For versioned import paths, the version<br>
is about the API, not the exact implementation. It's entirely<br>
OK to add new (backwardly compatible) features to a package that<br>
has a versioned import path (see "When to change the version" in<br>
<a href="http://gopkg.in" target="_blank">http://gopkg.in</a> for details on this).<br>
<br>
We use godeps to guarantee stable builds. That means that<br>
even in the presence of versioned import paths, we still want<br>
to pin the dependencies for testing purposes, so that we<br>
get reproducible tests and builds.<br>
<br>
Thus godeps and use of <a href="http://gopkg.in" target="_blank">gopkg.in</a> are orthogonal, and I think<br>
that the commits you mention look fine to me.<br></blockquote><div><br></div><div>+1</div><div><br></div><div>We do need to be careful about not letting fixes fall through the cracks in cases like this where there are commits to v3 after v4 has been created, but that's true of any branching of code.</div><div><br></div></div></div></div>