Not ideal, but you *could* release a new major version where the "breaking" change is the import path change. Eg if you are on v3 now, make a v4 folder and the upgrade to v4 process would involve updating import paths. I wouldn't do this right away since vgo is just a prototype and could change to handle this situation better, but it is an option.
On Fri, Feb 23, 2018 at 10:00 AM, Nic Pottier <nicpott...@gmail.com> wrote: > On Fri, Feb 23, 2018 at 7:59 AM, roger peppe <rogpe...@gmail.com> wrote: > > As Russ pointed out to me, you can work around that by using a > > 0.0.0-20000101234543-4f34f456eeefdcba version in your go.mod require > > section. If you've got that, it ignores the version tags. > > Right, that works for clients of the library (and I did manage to get > my projects working with that and it now feels magical) but authors of > modules above v1 are posed with a bit of a quandary as to how to give > their users a nice vgo version without breaking current users on plain > go. > > From Russ's latest post I think the answer is you put a v3 subdir in > your repo with a copy of the code, add a mod.go and update both the > root and v3 until vgo becomes adopted everywhere. > > -Nic > > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/golang-nuts/jFPz5yZCPcQ/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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.
