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 both version in master.
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 path to gopkg.in's,
but this let you keep v1 code only in v1 branch and remove it from master.
My opinion - no matter how promising vgo is, it's too early to give up on
go support. :) So, real question is not "to support go or not", but is "to
support v1 or not".
If your answer is "not", then feel free to remove it from master and let
v1 users either vendor it or rewrite import to gopkg.in. Moreover, in this
case you can avoid creating (arguably ugly) v2 directory - vgo should be
able to correctly handle v2 in repo root and use /v2 import path, while go
will continue using old (arguably wrong, but that's how everything works
now for most of packages anyway, and it will be fixed more of less
automatically when vgo will be released as go) import path.
--
WBR, Alex.
--
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.
