我正在与一位同事谈论我们使用的某些软件包的一种相当意外/不受欢迎的行为。尽管我们有一个简单的修复（或至少是解决方法），没有任何明显的副作用，但他强烈建议通过硬修补并将补丁发布到上游来扩展相关代码，希望在将来的某个时候被接受。事实上，我们会针对多个软件包的特定版本维护补丁，这些补丁会自动应用于每个新版本。主要论点是这是正确的做法，而不是“丑陋”的解决方法或脆弱的猴子补丁。另一方面，我更喜欢实用性而不是纯度，我的一般经验法则是“无补丁”>“猴子补丁”>“硬补丁”，至少对于（关键）错误修复以外的任何东西。
所以我想知道是否就何时更好地（硬）补丁、猴子补丁或只是尝试解决不能完全按照人们想要的方式解决第三方包达成共识。它是否主要与补丁的原因（例如修复错误、修改行为、添加缺少的功能）、给定的包（大小、复杂性、成熟度、开发人员响应能力）、其他原因或没有一般规则和一个应该根据具体情况决定吗？
打补丁是“正确的事”是有原因的：对于开源软件，如果你发现了一个真正的错误，或者需要一个你怀疑其他人可能也需要的功能，那么打补丁并在上游提交补丁是一种方法回馈社区，并为使软件整体变得更好做出贡献。如果补丁被接受，它是对您或您公司声誉的免费 +1。没有人会因为简历上有太多有用的开源代码示例而感到难过，他们为社区做出了贡献……
并不是说我们当时总是在战壕里做正确的事。但是，如果我们要对最佳实践进行抽象讨论，那么正确的优先顺序似乎是“补丁并提交”> 聪明的解决方法 > 找到一个更好的包 > 丑陋的猴子补丁 ;-)
我们缺少的一条信息是，您描述的意外行为是否是一个错误，纯粹而简单，或者它是否是包的某些消费者想要的行为。
正如其他人在这里所说，这是风险和努力的权衡。在不了解您的具体情况的情况下，我无法做出任何明确的断言。
然而，我的直觉是，假设您认为您的补丁会被接受，那么从长远来看，修补和推动上游将导致更少的风险和努力。不管你是硬补丁还是猴子补丁，你都会从中付出代价——每次更新你使用的包的版本时，你都必须测试你的补丁是否仍然有效，并可能根据情况更新它关于包的变化。使用硬补丁，您还必须重新应用补丁，但这很可能比您需要使用任一选项进行的测试/更新工作更少。
如我所见，在这种情况下修补有两个胜利。
如果您在升级时忘记了补丁，那么使用硬补丁，您的补丁将完全消失，很可能会导致灾难性且可见的故障。而对于猴子补丁，您的补丁仍然存在，但您不会测试它仍然具有相同的效果，在我看来，这比硬补丁完全丢失更危险。
硬补丁的另一个好处是，有了硬补丁，它最终应该被集成到包中，成本就消失了。而猴子补丁将无限期地存在，直到问题以某种方式独立解决。
如果意外行为是其他包消费者想要的，而不仅仅是一个错误，这会使我描绘的画面复杂化。在这种情况下，猴子补丁解决方案只需删除该行为。然而，硬补丁必须为那些想要它的人维护行为。
这种分析忽略了您可能对包维护者和其他消费者承担的任何道德义务。
另外，我在哲学上反对猴子修补的整个概念，但这与本次讨论无关:-)
在我看来：
如果 'unexpected/undesired behavior' != 错误，则将指示猴子修补（或打鸭子）。
如果您认为这是 lib 中的错误，那么硬打补丁并将补丁推送到上游是有道理的。
如果我理解您对“解决”的定义是为您的应用程序增加复杂性以补偿 lib 行为，我不得不说猴子补丁绝对是一个更好的主意。
我的 0.2 比索。
嗯，这是相当经典的风险与收益。
补丁没有风险吗？和重的好处？猴子补丁它。如果有一点风险，只有一点好处，我不会对其进行修补，只需将修复程序插入您的典型发布过程。