对于少数企业客户，我们应该多久发布一次开源解决方案？

Question

我的团队正在开发一个开源解决方案。 我们正在尝试确定管理发布和发布频率的最佳和最佳方式。 挑战在于各种客户在我们的核心产品之上开发代码，或者他们将其与第三方插件或软件集成，从而与现有代码库创建多个依赖关系。 由于向后兼容性问题，这使得重大更改变得棘手=> 升级对于我们的团队和我们的客户来说都是时间和精力密集型的。 客户必须通过每个版本升级步骤 go 以确保一切正常工作，我们必须进行大量的回归测试（即使其中大部分是自动化的）以确保我们没有搞砸旧项目。

当前 STATE：

我们开始每 2 周发布一次（与我们的 sprint 频率一致）。 目前我们正在尝试 3 周的频率。 我相信这种方法符合我们的开源社区需求，但这意味着我们的企业客户必须每年升级 14 次以上，或者如果他们不经常升级，他们必须通过漫长的升级过程来升级到 go，以确保他们已经完成了每个软件版本并运行每个迁移脚本（如果升级需要一个）。 请注意，我们不是 SaaS 解决方案，否则整个升级到新版本的过程会容易得多，我们只会遵循“发布越频繁越好”的口号。我们不能强制更改我们的代码现有用户。

潜在的解决方案：

我们正在考虑每季度发布一次，但上市速度很重要，代码稳定性和可靠性也很重要，这可能会受到这种方法的影响。

我们还在考虑每 2-3 周发布一次小版本的季度主要版本，以修复错误并让最终用户在 beta 中试用新功能，同时降低主要版本的风险并避免失去动力和部署实践。 然而，依赖管理和发布 scope 仍然很棘手。 最重要的是，这不会为我们节省任何时间，只会创造额外的工作。

问题：

如果有人对多久发布一次具有一些企业客户的开源软件的代码有任何建议，那就太棒了。