> If you wanna support go both for v1 and v2 using current import path then
> you've no choice - you have to keep both version in master.
Yeah, this seems to be the case.
There is an option to use gopkg.in to get alternate import path for v1.
> This way users of go+v1 will have to rewrite import
Hi!
On Thu, Apr 12, 2018 at 08:34:28PM -0700, Nick Snyder wrote:
> For (3) though, I am a little hesitant to delete the v1 code from master
> since this will break people go getting v1.
If you wanna support go both for v1 and v2 using current import path then
you've no choice - you have to keep
I am about to bump a Go library to v2. Here are some objectives that I have:
1. New import path for v2
2. Want it to work with go and vgo.
3. Prefer to avoid keeping v1 code around in master branch.
(1) and (2) are actually pretty easy. I just put the code in a new v2 dir
at the root of my proje