您应该多久发布一次软件更新？
不久前 Jeff Atwood 在 Twitter 上说了以下内容：
看，我喜欢快速的新软件发布，但 WordPress 发布的频率实在是太荒谬了。
这让我想到，您应该多久发布一次软件更新？
- 每天？
- 每周？
- 每月？
- 每年？
最好的发布策略是什么？
Moments ago Jeff Atwood said the following on twitter:
Look, I love rapid new software releases, but the frequency of WordPress releases is just ridiculous.
Which makes me think, how often should you release software updates?
- Daily?
- Weekly?
- Monthly?
- Yearly?
Whats the best release strategy?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（15）
我想说的是，在 WordPress 的具体情况下，它们将“安全更新”和“功能更新”混为一谈。 这不好。
这就像每次发现安全错误时都必须就地重新安装 Windows，而不是每周简单地下载一个小补丁。
WordPress需要有一个简单、快速、容易进行安全更新的安全补丁机制。 与新版本的正常升级流程分开的过程。
I would say in WordPress' specific case, they conflate "security updates" and "functionality updates". This is bad.
This would be like having to do an in-place reinstall of Windows every time a security bug was found, instead of simply downloading a small patch every week.
WordPress needs to have a security patch mechanism that's simple, fast, and easy for the security updates. A process that is separate from the normal upgrade flow of new versions.
Wordpress 发布的频率如此频繁，因为他们关心安全并发布更新来尽快修复已知漏洞。 Wordpress 的功能更新频率要低得多，我认为每 4 到 6 个月更新一次。
我认为这是一个很好的模式。 通过定期发布新功能来让您的客户满意，但如果您发现安全漏洞，请立即发布修复程序。
The frequency of Wordpress releases is so frequent because they care about security and release updates that fix known vulnerabilities as quickly as they can. Functionality updates to Wordpress happen much less frequently, in the range of every 4 to 6 months I think.
I think this is a good model. Keep your customers happy by releasing new features regularly, but if you find security flaws, release fixes immediately.
我建议如下：
updateTime（以秒为单位） - 用户执行更新所需的平均时间
releaseDelta（以天为单位） - 发布之间的最短时间
此公式基于我的理论，即用户应该花费时间任何一年中等待应用程序更新的时间不超过 8 小时。
这也允许频繁更新，只要更新以透明方式完成而不干扰最终用户即可。
I'll suggest the following:
updateTime (in seconds) - the average time it takes for the user to perform the update
releaseDelta (in days) - the minimum time between releases
This formula is based on my theory that a user should have to spend no more than 8 hours in any given year waiting for updates to an application.
This also allows for frequent updating as long as the updates are done in a transparent manner without disrupting the end user.
我认为这很大程度上取决于您的具体情况。 话虽这么说，我认为任何严肃的商业应用程序的每日发布都是完全可笑的。 如果您每天都发布，那么可能会出现严重的问题，除非您处于业务规则不断变化或类似情况的非常奇怪的情况下。
I think this highly depends on your particularly situation. That being said, I think a daily release for any serious business application just totally ludicrous. If you are releasing every day then there is probably a serious problem unless you are in some very strange situation where business rules change constantly or something like that.
比 iTunes 更新频率低。
Less frequently than iTunes updates.
我尝试使用以下（希望很简单）由两部分组成的指南：
因此，对于我们来说，桌面应用程序或 Web 服务之类的东西通常属于第一条规则，而我们的网站之类的东西则属于第二条规则。 我们进行了规模相当大的迭代——目前的开发时间约为四到六周，明年将减少到两到四周。 这是我们对 Scrum 混合体的“介绍”。
请注意，产品并不总是必须处于开发状态（或参与迭代）。 如果第一条规则适用，那么产品很可能会停滞不前，直到需要更改为止。
I try to use the following, hopefully simple, two-part guideline:
So, for us, things like desktop applications or web services would generally fall under the first rule, and things such as our web site would fall under the second. We run fairly good sized iterations - at about four to six weeks of development time currently, decreasing to two to four next year. This was our "introduction" into a Scrum-hybrid.
Note that a product doesn't always have to be in development (or participating in an iteration). It is quite possible that a product will sit, stale, until changes are needed if the first rule applies.
这取决于客户的配置控制方法。
他们有选择，你知道。 最终他们可以选择不使用你的产品。
如果客户接受你每天改变东西，并且他们不在乎，并且这对培训或配置管理没有影响； 有自动更新。
使用 SOE（标准操作环境）的客户讨厌更新。
意识到有些客户不会接受“打电话回家”软件。
他们会想要托管自己的更新。 他们的 IT 人员必须参与其中。
这对他们来说是更多的工作。
有些客户希望/需要自己进行质量检查； 取决于客户和软件类型。
如果客户需要进行测试/工作来接受/部署软件，请释放测试/部署周期长度的一些倍数。 除非客户同意交错部署和测试。 他们总是在那里测试新版本并推出它。
例如：测试 2 周，发布不超过每 8 周。
在结果关键的软件中，发布测试可能需要客户几个月的时间。 他们把自己的生意押在结果上，并且有理由保持谨慎。 因此每 6 个月左右发布一次。
在安全关键软件中，可能需要几个月的时间。 每年一次，或者大约每 18 个月一次，这种情况并不少见。 即使频率较低也是很正常的。
It depends on the customers approach to configuration control.
They have a choice, you know. Ultimately they can chose not to use your product.
If the customer will accept you changing stuff every day, and they don't care, and it has no training or configuration management impact; have automatic updates.
Customers with SOE ( Standard operating environments) hate updates.
Realize that some customers are not going to accept software "calling home".
They will want to host their own updates. Their IT people will have to get involved.
This is more work for them.
Some customers will want/need to do their own QA; depends on the customer and the kind of software.
If the customer needs to do testing/work to accept/deploy the software, release some multiple of the length of the test/deploy cycle. Unless the customers are okay with interleaved deploy and test. That's where they are always testing a new version, and the roll it out.
For example: 2 weeks to test, release not more than every 8 weeks.
In result critical software, release testing may take a customer months. They are betting their business on the results and are justifiably cautious. So releases are every 6 months or so.
In safety critical software, it may take MANY months. Annual, or about every 18 months is not uncommon. Even less often is quite normal.
没有正确的答案，这实际上取决于产品。
我说最多每月一次。 每周/每天太频繁了，除非应用程序更新以自动且透明的方式完成，例如 Firefox 的更新系统
There is no right answer, it really depends on the product.
I say monthly at most. Weekly/Daily is just too often, unless of course the application updates are done in a automated and transparent way, e.g. Firefox's update system
您可以根据需要多次释放它们。 让用户感到沮丧的是不知道他们是否需要您的新版本。 这意味着您需要非常清楚您实现了哪些新功能、修复了哪些错误以及是否修复了任何安全问题。 更重要的是，您的用户希望能够相信，如果他们安装了新版本，也不会出现任何问题。
You can release them as often as you want. The thing that frustrates users is not knowing whether they need your new version or not. This means that you need to be very clear about which new features you've implemented, the bugs that you've fixed, and whether or not you've fixed any security issues. More importantly, your users want to be able to trust that, if they do install a new version, nothing got broken.
我认为，如果可能的话，您应该在需要时自动更新您的软件，以便尽可能使整个更新过程对用户来说尽可能顺利且不可见。
I think that if it's possible you should have your software update automatically when it needs to, so as to keep the whole update process as smooth and invisible to the user as possible.
对于我工作的领域，工业控制，很少。 我们通常每两年发布一次主要版本。 小版本可能每 3 到 6 个月发布一次。 Bug补丁当然是另一回事，它们是根据需要发布的。 即使如此，也很少有客户会升级现有系统。 当然，在其他领域，升级更容易被接受。
For the area I work in, Industrial controls, very seldom. We typically do a major release very 2 years. Minor releases maybe every 3 to 6 months. Bug patch are of course a different story, they are released as needed. Even then few customers will upgrade existing systems. Of course in other domains, upgrades are more accepted.
当然，当您有值得发布的新功能/错误修复时？ 为什么要把它列入时间表？
Surely when you have new features/bug fixes worth releasing ?? Why have it on a schedule ?
我不反对一旦发现安全错误就立即修复 - 尽管我希望他们首先编写更健壮的代码。 我反对的（至少就 Wordpress 而言）是增强版本可能会破坏插件发生得太快。 从2.5到2.6花了多长时间？ 2.7 也很快就会发布。
自动或半自动升级可以缓解部分问题，但前提是插件编写者也升级，或者他们将安全修复与功能更改分开，这样我就可以坚持使用 2.5，但仍然保持最新的安全性补丁，直到我确定我使用的所有插件都适用于 2.6 或 2.7 或（到那时）4.0。
I have no objections to security bugs getting fixed as soon as they're found - although I wish they'd write more robust code in the first place. What I object (at least as far as Wordpress goes) is enhancement releases that could potentially break plug-ins happening too quickly. How long did it take to go from 2.5 to 2.6? And 2.7 is coming out very shortly as well.
An automatic or semi-automatic upgrade would mitigate some of that problem, but only if plugin writers upgrade as well, or if they separated security fixes from functionality changes so I could, say, stick with 2.5 but still be up to date with the security patches until I was sure all the plugins I use work with 2.6 or 2.7 or (by that time) 4.0.
每当需要他们的时候。 请记住，有些用户觉得定期获取更新更安全，而有些用户只是对每天弹出的“有 129 个新更新要安装！单击此处等待 20 分钟下载，然后再等待 10 分钟安装它们！”感到恼火。 ……你明白我的意思了。
Whenever they are required. Keep in mind some users feel more secure getting updates regularly, while some just feel annoyed having a pop-up every day "There are 129 new updates to install! click here to wait 20 minutes to download, then another 10 to install them!"... you see my point.
这取决于升级的性质以及完成升级所需的用户干预量。
如果它是一个网站，您可以每天升级，只要不破坏任何东西。
如果是免费的安全更新，那么尽快进行更新总是值得赞赏的。
免费的错误修复升级（如果必须由用户安装）不应超过每隔几个月进行一次。
任何必须付费的事情都不能超过一年一次，否则人们会开始觉得自己被利用了。 对于某些类别的软件（例如操作系统）来说更是如此。
It depends on the nature of the upgrade and the amount of user intervention necessary to accomplish it.
If it's a web site, you can upgrade every day, as long as you don't break anything.
If it's a free security update, ASAP is always appreciated.
A free bugfix upgrade, if it has to be installed by the user, shouldn't be more than every couple of months.
Anything that has to be paid for can't be more frequent than once a year, or people will start to feel taken advantage of. Even more for certain classes of software, such as operating systems.