一个大版本还是几个小版本？

Question

当您正在对现有业务线应用程序进行增强时，您是否认为将更改批量处理为较不频繁的较大版本，或者在较小版本中不断发布新功能？假设有硬件升级或数据库升级，您是否也对这些版本进行了这些更改，或者将它们分开？

将所有内容放在一起的优势在于，对业务的干扰更少，并且减少了非工作时间，但您以后遇到的任何问题都可能是由于数据库升级，硬件或任何数量的软件更改造成的。 / p>

发布很少，通常可以更轻松地追踪因发布而导致的任何问题，但会导致更多中断，并且会有更多时间用于回归测试。

哪个更好？

Answer 1

考虑每个版本如何影响客户。频繁的小版本会因为更快地解决关键问题而让他们更快乐吗？这会改善您的销售和声誉吗？如果它会仔细估计这些好处是否超过了额外的工作量，否则只需按照更方便的路径。

Answer 2

这实际上取决于你所处的环境。有些情况：

许多客户：您希望所有客户尽可能拥有相同的版本。由于测试和部署协调成本非常高，因此更容易获得日期，半年或季度大型版本。在这种情况下，我也会包含数据库更改。

“大型基础架构”：如果在具有操作系统和数据库专用人员的大型公司环境中工作，则版本的总体成本也很高，因此较不频繁的大型版本更好。< / p>

简而言之，计算人力，业务中断，协调，测试中发布的成本，并将其与每个新功能或错误修复的好处联系起来。

我通常倾向于每年发布1-2个大版本，并且在中间停止错误修复。

Answer 3

我认为最好的答案是：两者的混合。

例如，如果你添加一些眼睛糖果，或者使名称文本框更“ajaxy”，或者可能会投入一种新类型的报告 - 将其作为“小”版本。尽早发布，并尽可能经常发布。

另一方面，如果您更改了面向用户的流程，强制用户进行“重新培训”，或者如果您需要进行大规模的基础架构更改，请进行大规模发布，并尽可能少地使用。

正如你所说，如果很少或没有中断，尽可能多地做，你的用户会更乐意 - 而且你实际上会花费很少的时间进行回归测试，因为你只需测试连接的一切对你所做的改变。

Answer 4

就个人而言，我赞成大发行版。

我家里有软件，每周多次提供更新。这很烦人，因为没有自动更新功能，只是一个不断回来的通知。

您可能想看看这个类似的问题：How Often should you release software updates

Answer 5

我认为最好将其用于一个大版本并修补，因为您需要解决问题。

作为开发人员，您需要预测系统中可能存在的问题和中断，以使其尽可能强大。这通常意味着事先进行大量测试。

还要考虑最终用户可能不想为产品中较小的增量付费，他们也可能等待大的更新。一个很好的例子是当我使用Adobe Photoshop时，他们似乎每年都会发布一个新版本，所以我只是等到时间似乎是正确的

Answer 6

较少的版本意味着您将立即找到所有错误。知道哪个代码更改导致了哪个错误变得更加困难。然后你有更多关于级联错误的问题 - 你几个月前发生的一次代码更改导致了一个错误，但与此同时，你又做了五次更改，这些更改都取决于你几个月前提出的错误。

更小，更高质量的版本更好。较小的版本可以更容易地获得高质量。

Answer 7

事实上 - 两者兼而有之。
你有可能将开发分为DEVEL和RELEASE分支吗？任何紧急问题都应该尽快在REL分支上完成，并作为修补程序发送给用户。将修补程序应用到REL分支后，需要应用补丁程序将被发送给DEV团队（注意：要修复REL上的一些问题，你必须编写一些快速代码，而在DEV分支中你需要花一些时间重新思考建议的修复程序，由于DEV分支中的条件可能已经改变，因此通常会编写完全不同的代码来修复DEV或REL分支中的相同问题）。
在开发全新版本时，您必须测试从REL迁移的新功能和补丁。如果一切正常，您将能够部署全新的大版本，并将当前的DEV存档到REL中，而旧的REL现在将被封锁。