通常我们所有的升级，功能或错误修复都是增量的。这似乎是显而易见的，因为即使是开发错误修复，我们也会采用我们产品的最新代码库。但是，这导致要求我们的客户必须将软件更新到最新版本，甚至要修复错误，他们会获得功能以及错误修复。
最近，客户告诉我们他们希望能够获得错误修复补丁而无需使用新的功能增强功能。基本上他们希望修复bug但他们不想要新功能。这对我们来说是一个两难的选择。如果错误修复更改了与功能不同的二进制集，则可以执行此操作。但是，很多时候功能和错误修复都在同一个二进制文件中。
是否可以创建可以独立应用于任何软件版本的升级？别人这样做吗？ Microsoft或Office KB补丁是否是非增量的？任何指导或相关文章的链接都非常感谢。谢谢。
答案 0 :(得分：3)
客户想要的是正常的，但这并不意味着这是一个简单的问题。
您所描述的是配置管理的核心。 SCM不只是使用像git这样的工具，而是使用这样的工具来解决现有的需求。没有银弹，满足配置请求需要大量的工作和准备你的代码。我看到你没有将其标记为配置管理;如果你没有，这正是你需要研究的。
回到您的特定请求：客户希望能够在没有您不断使用的功能的情况下发布错误修复程序。出于这个答案的目的，我将假设您的商业模式是您提供的产品是生物，并且有几个客户订阅。
客户X，Y和Z都有不同的分支。与开发分支一起，您可以从中将功能/错误修复提供给需要它们的客户。
我认为这个解决方案通常非常具有挑战性（通常是SCM），您必须处理不同的代码库，开发人员必须非常了解您的工作流程。
对于每个已发布的版本都有一个分支，您可以通过错误修复修补而不引入新功能是我的建议。你的问题有点不清楚你的意思是增量，如果这个以某种方式引用补丁本身的分布，那么这是另一回事，这个答案就没用了。
您向客户提供了不需要它们的新功能，但它们隐藏在应用程序中的逻辑背后。这很难与你所描述的“完全改造”结合起来。这也有其他优点，因为它可以轻松执行A-B testing。
它对您的体系结构提出了要求，并且在涉及到允许的内容时也要遵守规则，每个小东西都有太多的功能标记，并且它可能无法维护。
您需要为此计划，否则您无法满足客户的需求。如果你的客户想要你需要谈判的错误的东西，这可能是非常好的。但是提供没有新功能的错误修复我认为是最小的
我读到的书籍是 old ，但是我记得这里有一个：Wayne A Babich：软件配置管理 - 团队生产力的协调
答案 1 :(得分：1)
Release Strategies可能会有所帮助。
LTS（长期支持的版本）部分似乎适用于您的问题。
关于你的问题：
后续问题：是否值得为软件用户进行额外的工作以促进非增量软件发布？
这个问题的答案取决于您的客户群，这可能需要与软件开发人员和市场营销人员长时间会面。如果想要非增量版本的客户在数量和收入方面都很重要，那么额外的工作可能是保留这些客户所必需的。