有没有人有关于提前发布/经常发布商业软件的经验/例子？它有效吗？
我在考虑 VMware，他们在每个主要版本之间都有很多修订版本。而且安装体验很糟糕，有时它们会破坏现有的虚拟机，有时客户操作系统中的 VMware Tools 会出现故障/无法安装。这太可怕了。
我也在考虑 ClickOnce 部署，因为当您更新软件时，使用 ClickOnce，所有客户端都会自动收到发布通知，并且只需单击一下，它们就会更新到新版本。如果您的软件有错误，那么它们也会自动“升级”以获取这些错误。
您是否有将提前发布/经常发布原则应用于商业软件的经验\示例\建议？
我想把它应用到一个。
肯尼是对的：这取决于。
我们致力于企业软件，客户可以在其中运行 3 个月以上的内部项目以升级到新版本。在那种环境下，频繁的发布是行不通的。客户将使用旧版本多年，我们必须继续支持他们，因此活跃的版本越多，支持工作就越多。
在另一个极端，我正在运行 Google Chrome 并阅读了有关 beta 更新的信息。我去看看如何获取它，发现Chrome已经更新了自己。如果有任何通知我错过了，那对我来说很好。
主要问题是新版本的破坏性有多大。例如，如果 MS 每 3 个月发布新版本的 Visual Studio，其中包含新的 .NET 版本、C 运行时等，那么我们将花费大部分时间来处理升级，这并不好。但是，如果他们想发布新版本的 Windows 媒体播放器和一些适合我的新小部件 - 只需让下载/安装过程尽可能无缝。
我认为这始终取决于您的市场或客户群。在某些环境和公司中，更改/升级软件总是很痛苦，甚至更痛苦。快速发布周期可能具有破坏性。这些中断通常也会延伸到您的内部运营，这取决于营销/管理层对功能蔓延的管理程度。
因此，经典的“视情况而定”答案再次响起。
如果您真的在为产品增加价值，那么客户尤其是新客户会想要它。最好的情况是消除升级更改的痛苦，因为它的工作原理相同，但明显更好。伟大的。
注意窗帘后面的人。：
Release Early-Release 通常实践希望您做的事情是尽早快速地失败，而不是在项目结束时为时已晚。它使您有更多机会向最终客户展示您正在构建的内容，获得有价值的反馈并以更低的成本进行调整。“客户”角色的人必须能够轻松获得最新版本；玩它并尽可能定期地以建设性的反馈做出回应。
如果您正在构建一些关键的东西，例如监控或控制发电厂的东西，您可能需要小心这种做法。您不希望人们拿着手电筒作为您新版本的反馈。在这种情况下，定期部署到测试平台，观察 X 天（根据您的信心水平）然后上线是有意义的！您可以让您的客户访问此测试平台，以发挥和建立他的信心表。
如果它是一个非关键应用程序，并且您拥有良好的发布历史记录，请执行 ClickOnce 之类的操作。但也要确保它同样容易为客户回滚。
如果您打算这样做，请确保当人们购买您的产品时，他们将在一年或其他一段时间内免费升级到新版本，这样他们就不会觉得自己在购买新产品时被骗了版本在他们购买副本后 2 个月发布。此外，请确保您支持旧版本，以便那些不想升级，只想修复错误的人可以这样做，而不会冒着用新版本的软件破坏他们当前安装的风险。我个人认为这将是更多的工作，但您最终会得到更好的产品，并且如果他们愿意，您将允许使用您的软件的人们更快地利用新功能。
我们运行一个 SaaS 应用程序，因此原则上它可以随时更新。
另一方面，在实践中，它每年只发布几个主要版本（通常每隔几周发布一次较小的补丁版本）。
原因是发布会给操作人员造成干扰；有时需要删除部分应用程序。对于非面向客户的更改，实际进行发布而不是进行工程设计需要做很多工作。
因此，虽然 StackOverflow 似乎每隔几天就会更新一次，但我们不会这样做。一天之内可能会修复几个错误，但它们会在随后的版本中得到修复，该版本以“大爆炸”的形式发布。或者其他的东西。
这取决于你的资源。如果你是微软，你可以提前发布一个与 Sista 押韵的漏洞百出的 POS，并依靠你的营销能力让人们忘记他们早期的产品体验。
如果您希望获得良好的口碑，发布早期版本不是一个好主意（除非您计划在最终发布之前更改名称或其他内容）。