17

不久前，杰夫阿特伍德在推特上说：

看，我喜欢快速发布新软件，但 WordPress 发布的频率实在是太荒谬了。

这让我想到，您应该多久发布一次软件更新？

  • 日常？
  • 每周？
  • 每月？
  • 每年？

最好的发布策略是什么？

4

15 回答 15

16

我想说，在 WordPress 的特定情况下，它们将“安全更新”和“功能更新”混为一谈。这是不好的。

这就像每次发现安全漏洞时都必须就地重新安装 Windows，而不是每周简单地下载一个小补丁。

WordPress 需要有一个简单、快速、易于安全更新的安全补丁机制。与新版本的正常升级流程不同的过程。

于 2008-12-11T16:57:57.650 回答
8

Wordpress 发布的频率如此频繁，因为他们关心安全性并发布能够尽快修复已知漏洞的更新。对 Wordpress 的功能更新发生的频率要低得多，我认为在每 4 到 6 个月的范围内。

我认为这是一个很好的模型。通过定期发布新功能让您的客户满意，但如果您发现安全漏洞，请立即发布修复程序。

于 2008-12-11T16:50:18.743 回答
8

我将建议以下内容：

updateTime (in seconds) - 用户执行更新的平均时间

releaseDelta（以天为单位） - 发布之间的最短时间

releaseDelta = updateTime/((1/365)*(60*60*8))

这个公式基于我的理论，即用户在任何一年中等待应用程序更新的时间都不应超过 8 小时。

这也允许频繁更新，只要更新以透明的方式完成，而不会干扰最终用户。

于 2008-12-11T16:57:58.977 回答
3

我认为这在很大程度上取决于您的具体情况。话虽如此，我认为任何严肃的商业应用程序的每日发布都是完全可笑的。如果您每天都发布，那么可能会出现严重问题，除非您处于业务规则不断变化或类似情况的非常奇怪的情况下。

于 2008-12-11T16:49:04.347 回答
2

比 iTunes 更新频率低。

于 2008-12-11T16:49:49.493 回答
2

我尝试使用以下（希望是简单的）两部分指南：

  1. 如果它要求用户下载和/或安装某些东西，或者更改他们维护的现有代码库，那么版本需要提供显着的优点。此版本添加了重要的新功能，修复了大量问题，或修复了较少数量的紧迫问题。
  2. 如果它不需要用户下载和/或安装版本，则将计划发生，如迭代所指示的。如果在迭代结束时有一个可发布的产品，它将被部署。迭代将包含在迭代开始之前确定的技术和业务需求。

因此，对我们而言，桌面应用程序或 Web 服务之类的东西通常属于第一条规则，而我们的网站之类的东西则属于第二条规则。我们进行了相当大的迭代——目前大约需要四到六周的开发时间，明年会减少到两到四周。这是我们对 Scrum 混合的“介绍”。

请注意，产品不必总是处于开发阶段（或参与迭代）。如果第一条规则适用，那么产品很可能会保持陈旧状态，直到需要进行更改。

于 2008-12-11T16:55:20.357 回答
2

这取决于客户对配置控制的方法。

他们有选择，你知道的。最终他们可以选择不使用你的产品。

如果客户愿意接受你每天更换的东西，而且他们不在乎，而且对培训或配置管理没有影响；有自动更新。

拥有 SOE（标准操作环境）的客户讨厌更新。

意识到有些客户不会接受“打电话回家”的软件。他们将希望托管自己的更新。他们的 IT 人员将不得不参与进来。这对他们来说是更多的工作。

一些客户想要/需要自己做 QA；取决于客户和软件类型。

如果客户需要进行测试/工作以接受/部署软件，请发布测试/部署周期长度的一些倍数。除非客户对交错部署和测试感到满意。这就是他们一直在测试新版本并推出的地方。

例如：2周测试，不超过每8周发布一次。

在结果关键软件中，发布测试可能需要客户数月时间。他们将自己的业务押在结果上，并且有理由保持谨慎。所以每 6 个月左右发布一次。

在安全关键软件中，可能需要几个月的时间。每年或大约每 18 个月一次并不少见。甚至更少是很正常的。

于 2008-12-11T21:50:42.227 回答
1

没有正确的答案，这真的取决于产品。

我说最多每月一次。每周/每天太频繁了，当然除非应用程序更新是以自动化和透明的方式完成的，例如 Firefox 的更新系统

于 2008-12-11T16:51:28.693 回答
1

您可以根据需要随时释放它们。让用户感到沮丧的是不知道他们是否需要您的新版本。这意味着您需要非常清楚自己实现了哪些新功能、修复了哪些错误以及是否修复了任何安全问题。更重要的是，您的用户希望能够相信，如果他们确实安装了新版本，则没有任何问题。

于 2008-12-11T16:51:58.677 回答
1

我认为如果可能的话，您应该在需要时自动更新您的软件，以使整个更新过程尽可能顺畅且对用户不可见。

于 2008-12-11T16:52:18.520 回答
1

对于我工作的领域，工业控制，很少见。我们通常会在 2 年内发布一个主要版本。次要版本可能每 3 到 6 个月发布一次。错误补丁当然是另一回事，它们会根据需要发布。即使这样，也很少有客户会升级现有系统。当然在其他领域，升级更容易被接受。

于 2008-12-11T16:55:10.607 回答
0

当然，当您有值得发布的新功能/错误修复时？为什么要按计划进行？

于 2008-12-11T16:54:55.753 回答
0

我不反对安全漏洞一经发现就得到修复——尽管我希望他们首先编写更健壮的代码。我反对（至少就 Wordpress 而言）是增强版本，它可能会破坏插件发生得太快。从 2.5 到 2.6 需要多长时间？并且 2.7 也将很快发布。

自动或半自动升级可以缓解一些问题，但前提是插件编写者也升级，或者如果他们将安全修复与功能更改分开，这样我就可以坚持使用 2.5，但仍保持最新的安全性补丁，直到我确定我使用的所有插件都适用于 2.6 或 2.7 或（到那时）4.0。

于 2008-12-11T16:58:36.403 回答
0

每当需要它们时。请记住，一些用户觉得定期更新更安全，而另一些用户则对每天弹出“有 129 个新更新要安装！单击此处等待 20 分钟下载，然后再安装 10 个！”感到恼火。 ……你明白我的意思。

于 2008-12-11T17:23:48.597 回答
0

这取决于升级的性质和完成升级所需的用户干预量。

如果是网站，你可以每天升级，只要不破坏任何东西。

如果它是免费的安全更新，我们总是很感激尽快。

免费的错误修复升级，如果必须由用户安装，不应该超过每两个月。

任何必须支付的费用都不能超过一年一次，否则人们会开始感到被利用了。对于某些类别的软件（例如操作系统）更是如此。

于 2008-12-12T02:25:14.200 回答