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
> 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.
> 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/
> To unsubscribe from this group and all its topics, send an email to
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.