blocks|key|1233788|text|考虑每个版本对客户的影响。频繁的小版本发布会因为更快地解决关键问题而让他们更高兴吗？这会提高你的销量和声誉吗？如果它会仔细估计这些好处是否超过了所做的额外工作，否则只需遵循对您更方便的路径。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1233789|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|1241522|text|就我个人而言，我更喜欢大版本。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1241523|我在家里有一个软件，每周更新几次。这很烦人，因为没有自动更新功能，只有不断返回的通知。|1241524|您可能想看一下这个类似的问题：How+Often+should+you+release+software+updates|offset|length|1241525|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/360028/how-often-should-you-release-software-updates^0|0|0|F|19|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

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: <a href="https://stackoverflow.com/questions/360028/how-often-should-you-release-software-updates">How Often should you release software updates</a>

blocks|key|4812991|text|我认为更好的做法是把它放到一个大的版本中，并在你需要修复问题的时候进行修补。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4812992|作为一名开发人员，您需要预测系统中可能出现的问题和中断，以使其尽可能地健壮。这通常意味着要提前做很多测试。|4812993|还要考虑到，最终用户可能不想为产品中较小的增量付费，他们可能会等待较大的更新。一个很好的例子是当我得到Adobe+Photoshop时，他们似乎每年都发布一个新版本，所以我只是简单地等待，直到时机成熟|4812994|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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

blocks|key|3969216|text|这真的取决于你所处的环境。一些场景：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3969217|许多客户:您希望所有客户都有相同的版本，尽可能。年度、半年度或季度大型发布要容易得多，因为测试和部署协调非常昂贵。在这种情况下，我也会包括对db的更改。|3969218|“大型基础设施”：如果在大型公司环境中工作，有专门的操作系统和数据库人员，那么发布的总体成本也很高，因此发布频率较低的较大版本更好。|3969219|简而言之，计算释放人力、业务中断、协调、测试的成本，并将其与每个新功能或错误修复的好处联系起来。|3969220|我通常一年会发布1-2个大的版本，并在其间修复bug，以阻止节目的播放。|3969221|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

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.

blocks|key|750335|text|较少的发布数量意味着您将一次找到所有的bug。要知道是哪种代码更改导致了哪种bug变得更加困难。然后，您就会遇到更多关于级联bug的问题--您几个月前所做的一个代码更改导致了一个bug，但在此期间，您又进行了另外五个更改，这些更改都依赖于您几个月前引入的bug。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|750336|更小、更高质量的版本更好。较小的版本更容易获得高质量。|750337|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|3969338|text|事实上，两者都有。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3969339|你能把开发分成DEVEL和RELEASE分支吗？任何紧急问题都应该尽快在REL分支上完成，并作为热修复程序发送给用户。将hotfix应用到REL分支后，需要应用补丁的问题将发送给DEV团队(注意:要修复REL上的一些问题，您必须编写一些快速代码，而在DEV分支中，您需要花费一些时间来重新考虑建议的修复，因为DEV分支中的条件可能已经更改，因此通常您会编写完全不同的代码来修复DEV或REL分支中的相同问题)。|3969340|当要开发全新的版本时，您必须测试从REL迁移来的新功能和补丁。如果一切正常，你将能够部署全新的大版本，并将当前的DEV归档到REL中，而旧的REL将被封存。|3969341|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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.

blocks|key|4813173|text|我认为最好的答案是:两者的混合体。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4813174|例如，如果你添加了一些令人眼花缭乱的东西，或者让textbox的名字更像"ajaxy"，或者可能加入了一个新类型的报表--把它设为“小”版本。尽早发布，并尽可能经常发布。|4813175|另一方面，如果你改变了一个面向用户的流程，迫使用户接受“再培训”，或者如果你需要大规模的基础设施改变--去做一个大的发布，并且尽可能少这样做。|4813176|正如您所说，如果很少或根本没有中断，那么尽可能多地这样做，您的用户会对此感到更高兴-而且您实际上将在回归测试上花费更少的时间，因为您只需要测试与您所做的更改相关的所有内容。|4813177|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

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.

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?

One big release or several small ones?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

当您正在对现有业务线应用程序进行增强时，您认为更好的做法是将更改批量处理到频率较低的较大版本中，还是在较小版本中不断发布新功能？假设有硬件升级或数据库升级，您是也随版本进行这些更改，还是将它们分开？将所有内容一起发布的好处是，对业务的中断更少，涉及的非工作时间也更少，但您以后遇到的任何问题都可能是由于数据库升级、硬件或...

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

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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