upgrade - 软件升级可以是非增量的吗？

Question

通常我们所有的升级、功能或错误修复都是增量的。这似乎是显而易见的，因为即使是为了开发错误修复，我们也会使用我们产品的最新代码库。然而，这导致要求我们的客户必须将软件更新到最新版本，即使是为了获得错误修复，他们也获得了功能和错误修复。

最近，客户告诉我们他们希望能够在不使用新功能增强的情况下获得错误修复补丁。基本上，他们希望修复错误，但不想要新功能。这对我们来说是一个两难选择。如果错误修复更改了与功能不同的一组二进制文件，则这是可能的。然而，很多时候功能和错误修复都在同一个二进制文件中。

是否有可能创建可独立应用于任何软件版本的升级？其他人这样做吗？ Microsoft 或 Office KB 补丁是否是非增量补丁？非常感谢任何指导或相关文章的链接。谢谢。

Answer 1

客户想要的很正常，但这并不意味着这是一个容易的问题。

您所描述的是配置管理的核心。 SCM不仅仅是用git这样的工具，它是用这样的工具来解决现在的需求。没有 Elixir ，满足配置请求需要大量工作和代码准备。我看到您没有将此标记为配置管理；如果您还没有，这正是您需要研究的内容。

回到您的具体要求:客户希望能够在没有您持续开发的功能的情况下发布错误修复。出于这个答案的目的，我假设您的商业模式是您提供一种有生命的产品，并且有多个客户“订阅”。

基于客户的分支策略

客户 X、Y 和 Z 都获得了不同的分支。连同一个开发分支，您可以从中将功能/错误修复提供给需要它们的客户。

我想说这个解决方案通常非常具有挑战性(SCM 通常是这样)，您必须处理不同的代码库，并且开发人员必须非常了解您的工作流程。

发布分支

我建议为每个已发布的版本创建一个分支，您可以在不引入新功能的情况下使用错误修复进行修补。你的问题有点不清楚你所说的增量是什么意思，如果这在某种程度上指的是补丁本身的分发，那就是另一回事了，这个答案就没那么有用了。

特征标志

您向客户提供了不需要它们的新功能，但它们隐藏在您应用程序的逻辑后面。这可能很难与您描述的“完全改造”相结合。这还有其他优势，因为它可以轻松执行 A-B testing .

它对您的架构提出了要求，并且在允许什么方面也有纪律，每件小事都有太多的功能标志，它可能变得无法维护。

制定策略

您需要为此做好计划，否则您将无法满足客户的需求。如果您的客户想要错误的东西，您必须进行谈判，这可能很好。但我认为只提供错误修复而不提供新功能是最起码的

我读的这方面的书旧，但无论如何我都记得:Wayne A Babich:软件配置管理 - 团队生产力的协调