自从Go 1.11发布以来，已经记录了几个与混合vgo和Go 1.11相关的问题，例如：#27562我建议将vgo更改为仅与Go版本范围[1.10.3,1.11)一起工作。
3qpi33ja1#
我们确实打算让vgo在需要时保持一种"下一个cmd/go的预览"。我不知道我们是否真的想切断1.11。尤其是因为vgo现在基本上就是"go 1.11 cmd/go"。
yuvru6vn2#
/cc @bcmills for thoughts
pbossiut3#
与@bcmills进行了交谈。计划是保持vgo不变。让vgo与1.10和1.11一起工作有好处，这样就可以在不改变所有提到vgo的地方的情况下使用vgo并更新到1.11。但是继续前进，vgo将不会被更新。一旦Go 1.12发布，Go 1.10将被弃用，届时所有支持的Go版本都将具有模块支持。然后我们可以完全删除vgo(可能在Go 1.12发布后的一个月左右)。
vxf3dgd44#
@bcmills - 一个删除所有代码的CL仍然会保留仓库。我想对于有管理员权限的人来说，最好还是在https://go.googlesource.com/vgo/彻底删除git仓库。
4条答案
按热度按时间3qpi33ja1#
我们确实打算让vgo在需要时保持一种"下一个cmd/go的预览"。我不知道我们是否真的想切断1.11。尤其是因为vgo现在基本上就是"go 1.11 cmd/go"。
yuvru6vn2#
/cc @bcmills for thoughts
pbossiut3#
与@bcmills进行了交谈。计划是保持vgo不变。让vgo与1.10和1.11一起工作有好处，这样就可以在不改变所有提到vgo的地方的情况下使用vgo并更新到1.11。但是继续前进，vgo将不会被更新。一旦Go 1.12发布，Go 1.10将被弃用，届时所有支持的Go版本都将具有模块支持。然后我们可以完全删除vgo(可能在Go 1.12发布后的一个月左右)。
vxf3dgd44#
@bcmills - 一个删除所有代码的CL仍然会保留仓库。我想对于有管理员权限的人来说，最好还是在https://go.googlesource.com/vgo/彻底删除git仓库。