> 想象一下，你自愿地让你的构建变得无法重现，因为它们依赖于时间。如果我现在构建我的应用，我会得到 libpupa 1.2.3 和 liblupa 0.7.8。如果我在10分钟后重复同样的构建，我会得到 liblupa 0.7.9。这很疯狂，对吧？但这其实完全合理，而这正是作者似乎没有理解的核心。开发者有其他动机，而不仅仅是可重现性。我们之所以有这种版本号方案，就是为了在改进代码的同时，也能合理地宣传兼容性的预期。如果我们有依赖项，那么这也会间接地提升他们的用户体验——无论是利用我们所做的优化，还是避免遇到我们实际有责任的错误等等。同样地，如果我们有依赖项，我们也可以利用这一点。升级环境是一个测试新配置的机会，看看它们是否比现有 lockfiles 中的配置更好。> 但这就是版本范围本质上所做的事情。…
源讨论我们本不应该需要锁文件原帖 287 条评论 · 导入时统计把你的经验，加入这段讨论。
> 不，实际上这是完全合理的，也是作者似乎没有理解的核心所在。开发人员有其他动机，而不仅仅是可重复性。我们有像这样的版本号方案的整个原因，是为了在改进代码的同时，也能合理地宣传兼容性的预期。如果我们有依赖项，那么这也会间接地改善他们的用户体验——无论是利用我们所做的优化，还是不会遇到我们实际有责任的错误等等。同样，如果我们有依赖项，我们也可以寻求利用这一点。 我实际上在这个问题上和作者意见一致，但将锁定文件提交到版本控制中会带来这种结果。
完整原文> 不，实际上这是完全合理的， 这就是我曾经在一个星期五晚上匆忙度过的缘故，因为一个依赖项决定在其补丁版本更新中放弃对“旧”语言版本的支持（即除了最新两个版本之外的所有版本）。而我所说的“放弃支持”是指“明确禁止使用低于此版本的语言进行构建”。 > 我们有这种版本号方案的整个原因，是为了在改进代码的同时，也能合理地宣传兼容性的预期。 当然，有些库作者故意破坏语义化版本控制，因为他们讨厌它，例如参见[0]中的引用，页面稍往下一点。 [0] https://dmytro.sh/blog/on-breaking-changes-in-transitive-dep...
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。