暴露依赖的小版本/补丁升级对SemVer的影响及API变更判定疑问

《语义化版本规范》（SemVer Specification）明确了不更新公共API时依赖变更的处理规则，但我始终搞不清到底什么才算公共API变更。

NPM示例 #

假设有一个库的peerDependency配置为"foo": "^1.0.0"，且该库对外暴露了foo的类型。如果把这个库的peerDependency更新为"foo": "^1.0.1"，这算不算API破坏性变更？目前有两种观点：

• 依赖"foo": "1.0.0"的使用者会受此变更影响无法正常运行，因此这属于API破坏性变更（需要对库进行主版本升级）。
• 大多数使用者会采用范围型依赖（比如"foo": "^1.0.0"），所以该变更具备兼容性，属于非API破坏性变更。

Rust示例 #

假设有一个库依赖foo = "1.0.0"。如果把依赖升级为foo = "1.0.1"，这算不算API破坏性变更？结合Rust文档中的这段描述：

同一兼容范围内不允许存在多个版本，若被限制在同一兼容范围内的不同版本，会导致解析器错误。

目前有三种观点：

• 依赖foo = "=1.0.0"的使用者会因为同一兼容范围内的版本冲突无法构建代码，因此这属于API破坏性变更。
• 大多数使用者会采用范围型依赖，版本会被自动解析为合适的新版本，因此属于非API破坏性变更。
• 只有当库暴露foo的类型时，这才属于破坏性变更。只有暴露其类型时foo才属于库的API，因此仅升级依赖不足以构成API破坏性变更。

我认为最后一种观点最符合SemVer的核心精神，但不确定在这个场景下是否适用。在我看来，无论是否暴露类型，受影响的用户群体是相同的，因此是否判定为破坏性变更不应该受这个因素影响。

内容的提问来源于stack exchange，提问作者quixotrykd