当您致力于增强现有的业务线应用程序时，您认为将更改批量化到不太频繁的较大版本中更好，还是在较小的版本中不断发布新功能更好？假设有硬件升级或数据库升级，您是在版本中也进行这些更改，还是将它们分开？
将所有内容一起发布的优点是对业务的干扰更少，涉及的工作时间更少，但您以后遇到的任何问题都可能是由于数据库升级、硬件或任何数量的软件更改造成的。
很少发布并且通常可以更轻松地跟踪发布导致的任何问题，但会导致更多中断和花费更多时间进行回归测试。
哪个更好？
【问题讨论】：
标签： release release-management
考虑每个版本对客户的影响。频繁的小版本发布是否会因为更快地解决关键问题而让他们更快乐？这会提高您的销售和声誉吗？如果它会仔细估计这些好处是否超过了所做的额外工作，否则就选择对你更方便的路径。
【讨论】：
这真的取决于你所处的环境。一些场景：
许多客户：您希望所有客户尽可能拥有相同的版本。每年、每半年或每季度发布一次大版本要容易得多，因为测试和推出的协调成本非常高。在这种情况下，我也会包括数据库更改。
“大型基础设施”：如果在大型公司环境中工作，并有专门的操作系统和数据库人员负责，那么发布的总体成本也很高，因此不太频繁地发布大型版本会更好。
简而言之，计算发布在人力、业务中断、协调、测试方面的成本，并将其与每个新功能或错误修复的好处联系起来。
我通常倾向于一年发布 1-2 个大版本，并在其间进行错误修复，以备不时之需。
【讨论】：
我认为最好的答案是：两者兼而有之。
例如，如果您添加了一些吸引眼球的东西，或者使名称文本框更加“ajaxy”，或者可能添加了一种新型报告 - 将其设为“小”版本。尽早发布，并尽可能经常发布。
另一方面，如果您更改了一个面向用户的流程，迫使用户接受“再培训”，或者如果您需要大规模更改基础架构 - 请进行大版本发布，并尽可能少做。
正如您所说，如果干扰很少或没有干扰，请尽可能多地进行，您的用户会因此而更快乐 - 而且您实际上会在回归测试上花费更少的时间，因为您只需要测试所有连接的东西您所做的更改。
【讨论】：
我认为最好将其整合到一个大版本中并在需要解决问题时进行修补。
作为开发人员，您需要预测系统中可能出现的问题和中断，以使其尽可能稳健。这通常意味着事先进行大量测试。
还要考虑到最终用户可能不想为产品中较小的增量付费，他们可能会等待大的更新。一个很好的例子是当我得到 Adobe Photoshop 时，他们似乎每年都会发布一个新版本，所以我只是等到时机成熟了
【讨论】：
更少的版本意味着您可以一次找到所有错误。很难知道哪个代码更改导致了哪个错误。然后，您在级联错误方面遇到了更多问题 - 您几个月前所做的一次代码更改导致了一个错误，但与此同时，您又进行了五次更改，这些更改都取决于您几个月前引入的错误。
较小的高质量版本会更好。较小的版本更容易获得高质量。
【讨论】：
就个人而言，我更喜欢大版本。
我家里有一个软件，它每周会提供多次更新。这很烦人，因为没有自动更新功能，只有不断回来的通知。
您可能想看看这个类似的问题：How Often should you release software updates
【讨论】：
事实上 - 两者兼而有之。
您可以将开发分为 DEVEL 和 RELEASE 分支吗？任何紧急问题应尽快在 REL 分支上完成，并作为修补程序发送给用户。在将修补程序应用到 REL 分支后，应用补丁的需求将发送给 DEV 团队（注意：要修复 REL 上的一些问题，您必须编写一些快速代码，而在 DEV 分支中，您需要花一些时间重新考虑建议的修复，因为 DEV 分支中的条件可能已经改变，所以通常你会编写完全不同的代码来修复 DEV 或 REL 分支中的相同问题）。
当全新版本的开发完成时，您必须测试从 REL 迁移的新功能和补丁。如果一切正常，您将可以部署全新的大版本，并将当前的 DEV 归档到 REL，而旧的 REL 现在将被封存。
【讨论】：