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