Yeah, it definitely makes sense to bring up this issue with upstream. They should indeed either commit to keeping their API stable, or use gopkg.in or similar.
On Thu, Jul 27, 2017 at 6:49 AM, Shengjing Zhu <i...@zhsj.me> wrote: > On Thu, Jul 27, 2017 at 9:23 PM, Martín Ferrari <tin...@tincho.org> wrote: > > On 27/07/17 14:05, Michael Stapelberg wrote: > >> It does break the API, as evinced by one build failure. > >> > >> I’m not aware of situations in the past where we created a new binary. > >> How would we name them? Is it worth the trouble? > > > > We had to do it once, for golang-github-dgrijalva-jwt-go-v3-dev > > > > It leaves the problem that, we need to fix the import path on every > package that depends on it. Take this package for example, the import > path need to be github.com/dgrijalva/jwt-go-v3 > > /me just wondering why upstream don't use gopkg.in/xxx as the import > path...when they has versioned api. > > > -- > Best regards, > Shengjing Zhu > -- Best regards, Michael
_______________________________________________ Pkg-go-maintainers mailing list Pkgemail@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers