Thanks for the great write up Dave, you've inspired me to "try harder" to 
use it on a few of my projects after running into similar issues.

As you noted, my remaining big question mark is how existing libraries that 
are above v1 transition to a vgo style while remaining backwards compatible 
during the transition. That seems like the biggest wrench to adoption. (if 
we can convince everyone to start using v# in import paths) I was preparing 
to open some PRs with dependencies of mine to introduce go.mod files, but 
as I understand it that won't be enough for those above v1.

On Friday, February 23, 2018 at 2:22:32 AM UTC-5, David Anderson wrote:
> I'm curious how we could upstream the changes I had to make to client-go. 
> I had to rename module-internal imports, which will break existing non-vgo 
> uses of the library, but vgo offers no alternative to this renaming that 
> I'm aware of. It looks to me like there's no graceful upgrade path for this 
> module. The repo structure works either for pre-vgo clients, or for vgo, 
> but not both at once.

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 
For more options, visit

Reply via email to