一个大版本还是几个小版本？
当您致力于对现有业务线应用程序进行增强时，您认为将更改批量化到频率较低的较大版本中更好，还是在较小的版本中不断发布新功能更好？ 假设有硬件升级或数据库升级，您是否也在版本中进行这些更改，或者将它们分开？
将所有内容一起发布的优点是可以减少对业务的干扰，并且减少非工作时间的工作，但是您以后遇到的任何问题都可能是由于数据库升级、硬件或任何数量的软件更改造成的。
少量且频繁地发布可以更容易地追踪发布所产生的任何问题，但会导致更多的中断和花费更多的时间进行回归测试。
哪个更好？
When you're working on enhancements to an existing line of business application, do you think it's better to batch up changes into less frequent bigger releases, or continually ship new features in smaller releases? Assuming there are hardware upgrades or database upgrades, do you make these changes with the releases as well, or keep them separate?
Releasing everything together has the advantage that there's less disruption to the business, and less out of hours work invovled, but any problem you later encounter could be due to the database upgrade, the hardware, or any number of software changes.
Releasing little and often makes it easier to track down any problems resulting from a release, but leads to more disruption and more time spent regression testing.
Which is better?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
考虑每个版本如何影响客户。 频繁的小版本发布会让他们因为更快地解决关键问题而更快乐吗？ 这会提高您的销售额和声誉吗？ 如果它会仔细估计这些好处是否超过所做的额外工作，否则就遵循对您来说更方便的路径。
Consider how each release affects the customers. Will frequent small releases make them happier because of solving critical problems faster? Will this improve your sales and reputation? If it will carefully estimate if these benefits outweight the extra work done, otherwise just follow the path which is more convenient for you.
这实际上取决于您所处的环境。一些场景：
许多客户：您希望所有客户尽可能拥有相同的版本。 每年、半年或每季度发布一次大版本要容易得多，因为测试和部署协调的成本非常高。 在这种情况下，我也会包含数据库更改。
“大型基础设施”：如果在拥有专门负责操作系统和数据库的人员的大型公司环境中工作，那么发布的总体成本也很大，因此频率较低的较大版本更好。
简而言之，计算发布在人力、业务中断、协调、测试方面的成本，并将其与每个新功能或错误修复的好处联系起来。
我通常倾向于每年发布 1-2 个大型版本，并在其间修复错误以防止出现问题。
It really depends on the environment your in. Some scenarios:
Many customers: You want all customers to have the same release, as far as possible. It is much easier to have anual, semianual or quarterly big releases, as the testing and rollout coordination is very costly. In this case I would include db changes as well.
"Big infrastructure": if working in a large company environment with dedicated personell for operating systems and databases, again the overall cost of a release is big and therefore less frequent larger releases are better.
For short, calculate the costs of a release in man power, business interuption, coordination, testing and bring it into relation with the benefits of each new feature or bug fix.
I usually tend to have 1-2 big releases a year and bug fixes inbetween for show stoppers.
我认为最好的答案是：两者的混合。
例如，如果您添加了一些养眼的东西，或者使名称文本框更加“ajaxy”，或者可能添加了一种新类型的报告 - 将其作为“小”版本。 尽早发布，并尽可能频繁地发布。
另一方面，如果您更改了面向用户的流程，迫使用户接受“重新培训”，或者如果您需要大规模的基础架构更改 - 则进行大版本发布，并尽可能少地发布。
正如您所说，如果中断很少或没有，请尽可能频繁地执行，您的用户会对此感到更高兴 - 而且您实际上会在回归测试上花费更少的时间，因为您只需要测试与更改相关的所有内容你做的。
I think the best answer is: a mixture of the two.
For instance, if you added some eye candy, or made the name textbox more "ajaxy", or maybe threw in a new type of report - make this as "small" releases. Release early, and release often, as possible.
On the other hand, if you changed a user-facing process forcing the users to be "retrained", OR if you are requiring massive infrastructure changes - go for a big release, and make this as seldom as possible.
As you said, if there is little or no disruption, do as often as possible, your users will be the happier for it - AND you will actually be spending LESS time on regression testing, because you only have to test everything connected to the changes you made.
我认为最好将其整合到一个大版本中并进行修补，因为您需要解决问题。
作为开发人员，您需要预测系统中可能出现的问题和中断，以使其尽可能强大。 这通常意味着事先进行大量测试。
还要考虑到最终用户可能不想为产品中较小的增量付费，他们可能会等待重大更新。 一个很好的例子是，当我购买 Adobe Photoshop 时，他们似乎每年都会发布一个新版本，所以我只是等待，直到时机成熟
I think its better to work it into one big release and patching up as you need to fix problems down the line.
As a developer you need to anticipate possible problems and breaks in your system to make it as robust as you can. That usually means much testing beforehand.
Also consider that the end user may not want to pay for the smaller increments in the product and they may as well wait for a big update. A good example of this is when I got Adobe Photoshop, they seem to release a new version every year so i simply waited until it seemed the time was right
版本数量较少意味着您将立即发现所有错误。 知道哪个代码更改导致了哪个错误变得更加困难。 然后，您会遇到更多级联错误的问题 - 几个月前所做的一项代码更改导致了错误，但与此同时，您又进行了另外五项更改，这些更改全部取决于几个月前引入的错误。
较小的、高质量的版本更好。 较小的版本更容易获得高质量。
A smaller number of releases means you'll be finding all your bugs at once. It becomes harder to know which code change caused which bug. You then have more of an issue with cascading bugs - one code change you made months ago has caused a bug, but in the meantime, you've made another five changes that all depend on the bug you introduced months ago.
Smaller, high-quality releases are better. Smaller releases make it easier to have high quality.
就我个人而言，我赞成大发布。
我家里有一个软件，每周会多次更新。 这很烦人，因为没有自动更新功能，只有不断返回的通知。
您可能想看看这个类似的问题：您应该多久发布一次软件更新
Personally, I favor big releases.
I have software at home which presents updates multiple times a week. It's annoying because there is no auto-update feature, just a notification that keeps coming back.
You might want to take a look at this similar question: How Often should you release software updates
事实上 - 两者都有。
您可以将开发分为 DEVEL 和 RELEASE 分支吗？ 任何紧急问题都应尽快在 REL 分支上解决，并作为修补程序发送给用户。 将修补程序应用于 REL 分支后，应用补丁的需求将发送给 DEV 团队（注意：要修复 REL 上的某些问题，您必须编写一些快速代码，而在 DEV 分支中，您需要花一些时间重新考虑建议的修复） ，由于 DEV 分支中的条件可能已更改，因此通常您会编写完全不同的代码来修复 DEV 或 REL 分支中的相同问题）。
当全新版本的开发完成时，您必须测试从 REL 迁移的新功能和补丁。 如果一切正常，您将能够部署全新的大版本，并将当前的DEV归档到REL中，而旧的REL现在将被封存。
In fact - both.
Can you possibly split development into DEVEL and RELEASE branch? Any urgent issues should be done ASAP on REL branch and sent out to users as a hotfix. After applying hotfix to REL branch, the need to apply patch would be sent to DEV team (note: to fix some issue on REL you have to write some quick code, while in DEV branch you need to put some time into rethinking the proposed fix, since the conditions in DEV branch might have changed, so it is common you would write completely different code to fix the same issue in DEV or REL branch).
When development of brand new version will be done, you have to test new features and patches migrated from REL. If everything is ok, you will be able to deploy brand new big version, and archive the current DEV into REL, while old REL will be now sealed off.