On Wed, Feb 21, 2018 at 1:10 PM, Bakul Shah <ba...@bitblocks.com> wrote: > On Wed, 21 Feb 2018 20:53:20 +0000 Henrik Johansson <dahankz...@gmail.com> > wrote: >> >> That's not necessarily true. >> The tool can understand from the tag and assert or even rewrite the imports >> to make the compiler happy. >> >> On Wed, Feb 21, 2018, 21:51 Sam Whited <s...@samwhited.com> wrote: >> >> > On Wed, Feb 21, 2018, at 14:46, Henrik Johansson wrote: >> > > But wait. Wasn't there a mention of archive downloads instead of relyin= >> g >> > on >> > > the different VCS's? >> > > >> > > In the GitHub case I guess it amount to downloading releases (or any >> > commit >> > > I guess) as a zip or tarball. >> > >> > My understanding was that the path is still relavant, so you'd need a /v2 >> > directory inside the zip file, which means you probably need it in your >> > source code. However, if that is incorrect it fixes the problem. > > As v2 is only created due to some incompatible change, in my > view it is better to have v2 visible in the path.
·Any· change to the exported API of a package except adding new top-level identifiers can be considered an incompatible (breaking) change. https://blog.merovius.de/2015/07/29/backwards-compatibility-in-go.html > Otherwise > it is easy for a reader to get confused when foo.F() in one > package (using v1) behaves differently from foo.F() in another > package (using v2) as they both will have the same import path > and only the "bindings" in their respective go.mod change. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
