据我所知，微软向社区发布的操作系统(通常是基于安全的)补丁和修补程序通常包含一系列更新的 DLL 或其他二进制文件。
Microsoft 和其他类似公司如何确保修补程序不会相互冲突？他们是否总是采用累积补丁方法，即单个修补程序将包含以前修补程序中的所有修补程序？事实似乎并非如此，因为许多修补程序似乎都专注于解决特定问题。如果它们是重点修补程序，它们如何防止一个修补程序破坏另一个修补程序(例如，彼此安装不兼容的 DLL)。
我一直钦佩 Microsoft 管理此流程的能力。我工作的公司规模要小得多，几年前当我从事补丁流程时，我们总是采用累积方法，即单个补丁立即取代基于该版本的所有先前补丁。这意味着补丁的大小逐渐变大，直到下一个“官方”版本发布。
管理补丁依赖项有哪些好的做法？
最佳答案
首先，Microsoft Windows Installer 能够直接修补二进制文件。给定文件的已知早期状态，它可以将它们带到已知的当前状态。我们曾经为我们的大型商业产品这样做，但在几次发布之后，我们的四路系统需要长达 24 小时才能生成补丁 - 当您拥有(或想要拥有)时，这并不好每晚构建。
过了一段时间，我们选择了累积修复，只允许升级。我们检查你的水平较低，然后基本上更换整个产品。 (我们还遇到过第二个或第三个“增量”基本上就是一切的情况。)
在 Unix/Linux 上，显然我们不能使用 MSWI，因此我们提供了另一个安装程序，它基本上做同样的事情:将所有文件移开，像全新的一样安装，然后删除备份。现实是，对于我们的业务来说，这已经足够了。据我所知，我们还没有收到任何投诉(根据我目前的工作，这些投诉很快就会打击我)，人们不满意，可以实际打电话投诉。大多数情况下，他们希望通过补丁获得更新的级别，以便他们可以继续他们的实际业务。 奇怪的是，他们的业务并不是安装补丁。
关于patch - Microsoft(以及其他拥有大量安装基础的软件公司)如何管理补丁依赖性？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/224515/