CC @jayconrod@thepudds @jadekler @tbpg

+1,看起来不错。这似乎应该是一个规范，apidiff(cc @jba)和相关指南都参考了它。你们觉得呢？

很难找到一个能让每个人都同意的兼容性的定义(参见 Hyrum's Law )。
我同意我们应该对这个主题有一些规范的文档。
相关 #33637
相关 #26420

很难找到一个能让每个人都能同意的兼容性定义(参见 Hyrum's Law )。
我一直认为这是编译时兼容性，因为运行时兼容性如果不是不可能的话是很难实现的，正如apidiff文档中提到的。我认为针对它是否能编译的目标是可以实现的，apidiff接近于我将发布的包规范，如果不是完全一样的话。

是否需要额外的信息，或者这个提案在Hold上，但没有正确标记？它似乎错过了前几次提案审查会议：#33502。

我认为这个提议没有任何反对意见。我们至少可以批准这个倡议和最终的地点，这样有人(乐意效劳)就可以开始编写一份单一的文件了吗？

现有文档为什么不够？特别是，apidiff似乎记录了一个自动检查的API兼容性概念，据我所知，这是Go团队维护的。为什么这不完全是你想要的“单一文档”？
为什么模块需要单独处理？在我看来，一个模块只要其所有非内部包兼容(在某种意义上由你喜欢的API兼容性概念定义),那么它就是兼容的，这一点相当明显。

To be more specific: I don't really understand what the problem you are trying to solve is. On the one hand, you seem to perceive it as a problem that there are too many documents describing compatibility - on the other, you seem to be suggesting to write another.
IMO the Go 1 compatibility guarantee is a statement about the Go project with a notion of compatibility that is appropriate for this project - that doesn't mean it should be considered a recommendation for how third party Go code should handle compatibility. You also mention the spec (which, AFAICT, doesn't mention compatibility in this sense at all). And a blog post about modules, which, IMO, is not the same as documentation (in particular, blog posts are not normally living documents that are kept updated, whereas documentation is). Lastly, you mention a third party tool, over which we have no control.
So, the only reasonable documentation of API compatibility in the list, as far as I can tell, is the one provided by apidiff . Which brings back to the question of "why is that not exactly what you want?" :)

请注意，本文尝试讨论如何保持API的兼容性：
https://blog.golang.org/module-compatibility
我认为这是在这个问题提交后发布的。