现代软件控制依赖关系，因为它可以帮助软件作者

热门提示：每个分发打包者都说您不应该捆绑依赖项是暗中告诉软件作者＆＃34;您应该为我们做更多的工作，并限制您软件的功能（和可靠性）。

（这是通过阅读《现代包装商的安全性噩梦》引发的，我并非完全站在另一侧，但我确实认为发行版应该诚实对待他们的要求，而Idon则不认为他们将得到它。）

这个热点很窄。真正重要的是软件作者和现代软件系统限制了依赖版本（最大版本和最小版本）。最重要的是，显式或隐式捆绑只会使分发问题变得更糟。

对于软件作者而言，限制与之打交道的依赖版本会减少他们要做的工作量，既要针对一定范围的版本进行测试，又要永远追逐那些依赖所要进行的更改或永远限制依赖关系的功能他们使用可用的旧版本（有时同时使用两个版本）。从理论上讲，至少对于单个程序而言，语义版本控制（如果每个人都遵循它）将处理更改后的测试和跟踪。在实践中，不仅人们容易犯错，而且人们对语义版本控制的含义也有不同的理解，因为语义版本控制最终是一种社会事物，而不是技术问题。我们的领域历史表明（有时生动地），如果软件作者允许依赖版本继续向前发展，那么事情迟早会中断，软件作者必须对其进行修复。

（还有一个实际问题，即并非所有依赖项都首先宣称或同意遵循语义版本控制。）

对于发行商而言，一旦软件作者开始限制版本，发行商就会遇到升级问题和发行问题。在升级方面，处理程序中的问题可能现在需要说服它接受新版本的依赖项。在分发方面，现在很可能您将拥有多个程序，这些程序对于相同的依赖项具有不同的版本要求。至少，这会使涉及的软件包成倍增加。

（许多发行版还存在软件包系统设计问题，这些问题限制了它们可以同时安装的事物的版本范围。即使在语义版本控制下，当您拥有两个程序的版本要求相互冲突且可能会＆＃39时，这也是发行版的问题。 ; t同时打包和安装。）

但是，这里没有免费的午餐。发行人在要求不受捆绑的不受版本限制的依赖项时想要的是让软件作者进行工作以接受其依赖项的任何版本，或者至少接受SemanticVersioning内的任何版本，并忠实遵循semver的依赖项，并使打包和安装成为可能至少同时使用不同的主要版本。接受广泛的依赖关系版本是实际的工作，即使它可能会限制代码和软件的功能，也可能会受到限制。软件包生态系统的创建者和创建者（例如Go和Rust）不拒绝这样做，因为他们不喜欢发行版。他们拒绝这样做，是因为他们一遍又一遍地发现这并没有真正起作用，并且从长远来看确实会给软件作者（通常是程序用户）带来问题。

（最明显地经历了这种体验的软件社区是Go，它最初是内部无版本的依赖关系，默认情况下，该依赖关系在所有程序中普遍使用，并且在许多人对该初始状态有很多问题之后，最终切换为强版本化的依赖关系Go遇到了很多问题，以至于他们采用了异常严格且软件作者友好的版本控制方案。）

人们普遍认为，即使发行版不是要软件作者也应该这样做，所以实际上他们没什么大不了的。对于提出论点的人来说，这是很方便的，但是并不能使论点有效。软件作者从不欠任何人任何工作。他们所做的一切工作都能满足他们的需求，并且对他们来说很有趣。由于时间和兴趣有限，软件作者为自己的开发进行优化既合理又适当。

PS：通常，发行版还希望所有软件的某种组合能够更新到其依赖项的最新版本，并具有要显式支持较旧版本的依赖项。对于软件作者来说，这也是额外的工作，尤其是当发行版也希望针对较旧版本的程序进行发行时。