在模块页面的右侧，有像“稳定版本”和“可再分发许可证”这样的复选框。我认为我们还应该添加一个类似于“遵循semver”的复选框。也就是说，次要或修复版本不会反复进行明显不兼容的更改，例如删除整个功能或包。
以下是一个明显的破坏的例子：https://pkg.go.dev/google.golang.org/grpc/naming
该页面确实显示了一个This package is not in the latest version of its module警告，但通常在更新模块并发现由于现在缺失的包而导致的构建失败后，人们才不会找到这样的警告。
换句话说，如果我在查看哪些模块作为依赖项时，我看到了https://pkg.go.dev/google.golang.org/grpc,如果看到以下警报之一，我会三思而后行是否添加该模块：
- 最后一次破坏是在日期(或版本)
- N个v1版本包含破坏性更改(或*N%*个稳定的v1版本)
- N个包自v1.0.0以来发生了破坏性更改(或*N%*的总包数)
请注意，我只以grpc为例，因为它是我最近遇到的最大问题。该功能同样适用于任何其他使用稳定semver标签的v1+模块，但它们会主动违反semver兼容性规则。
cc @bcmills @heschik @julieqiu@leitzler
3条答案
按热度按时间elcex8rz1#
我倾向于仅报告每个次要版本的最新补丁版本中找到的破坏性更改。
(在一个随后的补丁版本中纠正的破坏性更改可以说是“只是一个错误”——它应该计入“错误发布频率”，但不应计入“有意破坏性更改的频率”。)
ltskdhd12#
这对我来说听起来很合理。如果后续的修复/补丁版本完全解决了这个问题，我认为这通常应该使
go get -u不再受到影响。仅报告在最新补丁版本中找到的破坏性更改
我猜你的意思是相对于其主要版本的第一个发布版本而言的破坏性更改，而不是相对于紧接着的前一个发布版本而言。也就是说，如果v1.0.1删除了v1.0.0中存在的一个包，而v1.0.2仍然缺少该包，那么v1.0.2仍然包含破坏性更改，尽管它本身没有直接删除一个包。
qoefvg9y3#
我猜你的意思是相对于主要版本的第一个发布版本进行破坏，而不是相对于紧接着的前一个发布版本。
是的。具体来说，相对于任何前一个次要版本的最新补丁版本进行破坏。
(如果模块作者通过将破坏性更改回溯移植到每个前一个次要版本的补丁版本来“作弊”。。。我想这可能是SemVer的一个灰色地带？它基本上是在说“这个东西曾经起作用本身就是一个严重的错误”，这与Go 1兼容性策略中的“安全”例外相似。)