【发布时间】：2010-09-26 11:29:11
【问题描述】：
不久前Jeff Atwood said the following on twitter：
看，我喜欢快速发布新软件，但 WordPress 发布的频率实在是太荒谬了。
这让我想到，您应该多久发布一次软件更新？
- 每天？
- 每周一次？
- 每月？
- 每年？
最好的发布策略是什么？
【问题讨论】：
标签： release release-management
【发布时间】：2010-09-26 11:29:11
【问题描述】：
我想说，在 WordPress 的特定情况下，它们将“安全更新”和“功能更新”混为一谈。这很糟糕。
这就像每次发现安全漏洞时都必须就地重新安装 Windows，而不是每周简单地下载一个小补丁。
WordPress 需要有一个简单、快速且易于进行安全更新的安全补丁机制。与新版本的正常升级流程不同的过程。
【讨论】：
-
v2.7 具有自动更新功能...希望它会让这更容易。
Wordpress 发布的频率如此之高，因为他们关心安全性并发布能够尽快修复已知漏洞的更新。 Wordpress 的功能更新频率要低得多，我认为大约是每 4 到 6 个月一次。
我认为这是一个很好的模型。通过定期发布新功能让您的客户满意，但如果您发现安全漏洞，请立即发布修复程序。
【讨论】：
-
我不同意。没有人抱怨 Wordpress 正在快速修复安全问题，他们抱怨他们从 2.5 升级到 2.6 并很快升级到 2.7，功能发布可能会破坏插件，太快了。
-
当您的文字处理器甚至可能出现安全问题时，某些东西从根本上就被破坏了。
-
skiphoppy，“Wordpress”是一个博客引擎，而不是文字处理器。任何网络应用都可能存在安全问题。
我会提出以下建议：
updateTime (in seconds) - 用户执行更新的平均时间
releaseDelta（以天为单位） - 发布之间的最短时间
releaseDelta = updateTime/((1/365)*(60*60*8))
这个公式基于我的理论，即用户在任何一年中等待应用程序更新的时间都不应超过 8 小时。
这也允许频繁更新，只要更新以透明的方式完成，不会干扰最终用户。
【讨论】：
-
大约 releaseDelta = 0.01 * updateTime
我认为这在很大程度上取决于您的具体情况。话虽如此，我认为任何严肃的商业应用程序的每日发布都是完全可笑的。如果你每天都发布，那么可能会出现严重问题，除非你处于业务规则不断变化或类似情况的非常奇怪的情况下。
【讨论】：
比 iTunes 更新频率低。
【讨论】：
-
我不会介意频繁的 iTunes 更新，如果他们没有让我之后重新启动的话。为什么升级音乐播放器需要重启？
-
而且我不使用的 .mac 和 safari 的无意义更新真的很烦人。
-
啊。我喜欢这个答案。 +1 当我真的再次获得选票时。
-
我最讨厌 iTunes 在您启动它时需要数年时间来检查更新，而且它们甚至不会显示一个小的启动屏幕来让您知道您甚至点击它是正确的。跨度>
-
@MusiGenesis - 您必须在 Windows 上。在 Mac 上，它与 OS 更新集成在一起，所以偶尔我会弹出“以下更新已下载，请单击此处安装它们”。
我尝试使用以下简单的两部分指南：
- 如果它要求用户下载和/或安装某些东西，或者更改他们维护的现有代码库，那么版本需要提供显着的优点。此版本添加了重要的新功能，修复了大量问题，或修复了少量即时和紧迫的问题。
- 如果不需要用户下载和/或安装，则将计划发布版本，如迭代所指示的那样。如果在迭代结束时有一个可发布的产品，它将被部署。迭代将包含在迭代开始之前确定的技术和业务需求。
因此，对我们而言，桌面应用程序或 Web 服务之类的东西通常属于第一条规则，而我们的网站之类的东西则属于第二条规则。我们进行了相当大的迭代——目前大约需要四到六周的开发时间，明年会减少到两到四周。这是我们对 Scrum-hybrid 的“介绍”。
请注意，产品不必总是处于开发阶段（或参与迭代）。如果第一条规则适用，那么产品很有可能会过时，直到需要更改。
【讨论】：
这取决于客户的配置控制方法。
他们有一个选择，你知道的。最终他们可以选择不使用您的产品。
如果客户愿意接受你每天更换的东西，而且他们不在乎，而且对培训或配置管理没有影响；有自动更新。
拥有 SOE（标准操作环境）的客户讨厌更新。
意识到有些客户不会接受“打电话回家”的软件。 他们将希望托管自己的更新。他们的 IT 人员将不得不参与其中。 这对他们来说是更多的工作。
一些客户希望/需要自己进行质量检查；取决于客户和软件类型。
如果客户需要进行测试/工作以接受/部署软件，请发布测试/部署周期长度的倍数。除非客户对交错部署和测试感到满意。这就是他们一直在测试新版本并推出的地方。
例如：2周测试，不超过每8周发布一次。
在结果关键软件中，发布测试可能需要客户几个月的时间。他们把赌注押在结果上，并且有理由保持谨慎。所以每 6 个月左右发布一次。
在安全关键型软件中，可能需要几个月的时间。每年或大约每 18 个月一次并不少见。更少是很正常的。
【讨论】：
没有正确答案，这真的取决于产品。
我说最多每月一次。每周/每天太频繁了，除非应用程序更新是以自动化和透明的方式完成的，例如火狐的更新系统
【讨论】：
您可以根据需要随时释放它们。让用户感到沮丧的是不知道他们是否需要您的新版本。这意味着您需要非常清楚自己实现了哪些新功能、已修复的错误以及是否已修复任何安全问题。更重要的是，您的用户希望能够相信，即使他们安装了新版本，也不会出现任何问题。
【讨论】：
我认为如果可能您应该在需要时自动更新您的软件，以便让整个更新过程对用户保持流畅和不可见尽可能。
【讨论】：
-
不得不说，这在很大程度上取决于软件。举一个明显的例子，如果我管理的生产机器上的服务器软件自动更新，我会吓坏的。人们需要能够控制他们的软件。
对于我工作的领域，工业控制，很少见。我们通常会在 2 年内发布一个主要版本。次要版本可能每 3 到 6 个月发布一次。错误补丁当然是另一回事，它们会根据需要发布。即使这样，也很少有客户会升级现有系统。当然在其他领域，升级更受欢迎。
【讨论】：
当然，当您有值得发布的新功能/错误修复时？为什么要按计划进行？
【讨论】：
-
曾经不得不做一些叫做“资源规划”的事情吗？
我不反对安全漏洞一经发现就得到修复——尽管我希望他们首先编写更健壮的代码。我反对（至少就 Wordpress 而言）是增强版本，它可能会破坏插件发生得太快。从 2.5 到 2.6 需要多长时间？并且 2.7 也即将推出。
自动或半自动升级可以缓解部分问题，但前提是插件编写者也升级，或者如果他们将安全修复与功能更改分开，这样我就可以坚持使用 2.5 但仍保持最新使用安全补丁，直到我确定我使用的所有插件都适用于 2.6 或 2.7 或（到那时）4.0。
【讨论】：
在需要时。请记住，一些用户觉得定期更新更安全，而另一些用户则对每天弹出“有 129 个新更新要安装！单击此处等待 20 分钟下载，然后再安装 10 个！”感到恼火。 ...你明白我的意思。
【讨论】：
这取决于升级的性质和完成升级所需的用户干预量。
如果是网站，你可以每天升级，只要不破坏任何东西。
如果它是免费的安全更新，我们总是很感激尽快。
如果必须由用户安装，免费的错误修复升级不应超过每两个月一次。
任何必须支付的费用都不能超过一年一次，否则人们会开始感到被利用了。对于某些类别的软件（例如操作系统）更是如此。
【讨论】：