<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 28, 2015 at 1:09 AM, Aaron Jacobs <span dir="ltr"><<a href="mailto:jacobsa@google.com" target="_blank">jacobsa@google.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="">On Mon, Jul 27, 2015 at 4:45 PM, Michael Stapelberg<br>
<<a href="mailto:stapelberg@debian.org">stapelberg@debian.org</a>> wrote:<br>
> As I tried to explain before, we cannot use your vendored copies, and the<br>
> tarballs we’ll create of your source code will not even contain the vendor/<br>
> directory.<br>
<br>
</span>Sorry, I had totally forgotten that you said this.<br>
<br>
Please forgive me if you've already answered the following, but I can't find it<br>
above: what is the convention for dealing with backwards-incompatible changes<br>
in Go libraries? If the library author tags with semantic versions and bumps a<br></blockquote><div><br></div><div>The Go community’s stanza is you should never do backwards-incompatible changes, AIUI. Personally, I’d publish a new library under a different import path.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
major version, are you able to cope with that, even if there are some binaries<br>
that need the old version and some that need the new?<br></blockquote><div><br></div><div>I think we’d most likely have to patch packages which have not yet been updated.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> FWIW, the only blocker currently to get gcsfuse uploaded is<br>
> <a href="https://github.com/GoogleCloudPlatform/gcsfuse/issues/93" rel="noreferrer" target="_blank">https://github.com/GoogleCloudPlatform/gcsfuse/issues/93</a><br>
<br>
</span>Cool. I've switched to codegangsta/cli itself, so I believe this shouldn't be<br>
an issue anymore. Tagged v0.4.0 for you to work from.<br>
</blockquote></div><br>Indeed. Currently, when building, I get:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra"># <a href="http://github.com/googlecloudplatform/gcsfuse/fs">github.com/googlecloudplatform/gcsfuse/fs</a></div><div class="gmail_extra">src/<a href="http://github.com/googlecloudplatform/gcsfuse/fs/fs.go:203">github.com/googlecloudplatform/gcsfuse/fs/fs.go:203</a>: cannot use fs (type *fileSystem) as type fuseutil.FileSystem in argument to fuseutil.NewFileSystemServer:</div><div class="gmail_extra"><span class="Apple-tab-span" style="white-space:pre">        </span>*fileSystem does not implement fuseutil.FileSystem (wrong type for CreateFile method)</div><div class="gmail_extra"><span class="Apple-tab-span" style="white-space:pre">          </span>have CreateFile(context.Context, *fuseops.CreateFileOp) error</div><div class="gmail_extra"><span class="Apple-tab-span" style="white-space:pre">          </span>want CreateFile(*fuseops.CreateFileOp) error</div><div><br></div><div>I might be able to take a look at that later this evening, but if you happen to know what the issue is, that might save me some time. I’m guessing one of the dependencies was changed in a backwards-incompatible way :).</div><div><br></div>-- <br><div class="gmail_signature">Best regards,<br>Michael</div>
</div></div>