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 to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
