> 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 path to gopkg.in's, > but this let you keep v1 code only in v1 branch and remove it from master. An interesting option that I hadn’t thought about, but forcing existing users to update import paths seems undesirable. 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". I agree that it is too early to require users to use vgo. Any solution has to work with the normal go command. 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. I don’t want to require vgo at this point so I think I am stuck with a subdirectory for now. If vgo proposal is accepted and implemented in the go command, then I think I will be able to get rid of the v2 directory and v1 code in master. -- 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.
