我们是否应该为开放 SaaS 考虑版本管理方案?

由于开放 SaaS 的使用已经相当普遍，我很好奇，是否有必要考虑某种版本控制方案。我们可以使用类似于 open-saas 1.0.0、1.2.1、2.0.0 这样的版本号。如果我们不需要它（暂时），那么最好不要过于复杂，但我想探索一下，是否有用。1. 文档。现在使用了 Wasp 0.12 的 OpenSaas，我们没有使用 Wasp 0.11 的文档。最大的区别在于文档中关于入门的内容，我认为，但仍然，文档中存在其他差异，如果我是 0.11 的用户，我就无法再回去查看旧的文档，而不需要检查 OpenSaas 仓库中的旧提交并自己托管它们。而且我不知道应该去哪个提交，因为没有简单的方法来找出这一点（没有标签）。实际上，我除了文档之外没有很强的理由。Open Saas 在某种意义上非常特殊，因为它是一个模板，一旦你检查出来，就可以继续使用，没有太多理由回来，除了文档。没有可拉取的更新。但文档非常重要。此外，我们如何遵守 Semver 并不那么明确：什么是主要的更改，什么是次要的，什么是补丁？好吧，我们应该能弄清楚这一点。也许这会回答“如果我尝试将当前项目与模板的新状态合并，会发生什么”这一问题。是的，这可能是有意义的。所以 Semver 可能是完全可以的。另一个问题是，我们是否可以接受“主”始终是“发布”的最新版本的 Open Saas？目前，我认为情况就是这样 ->“主”始终可以使用。这意味着“主”不应处于破坏状态，我们期望它始终工作，具有正确的文档，并经过充分测试。如果功能在功能分支上开发，然后在它们得到充分测试后才合并到“主”中，这是可行的。也许这也是当前的正确方法。或者，我们可以有一个“发布”分支，类似于我们对 Wasp 的做法，然后在准备好时对其进行发布。GitHub 模板将从中获取（可以配置），我们将在合并“主”到“发布”之前进行全面测试/打磨。这意味着我们可以对“主”更加随意，如果需要，可以在一段时间内破坏一些东西。然后，为每个版本发布可能就有意义。我不确定这里更好，我实际上可能会坚持现在的做法，因为它更简单，如果它起作用，它就起作用，但在这种情况下，我们应该加强我们的测试工作，并将此信息记录在 README 中。在此之上，无论我们对所有这些问题的回答是什么，我们都应该确保在 README.md 中记录相关的决策/流程，以便其他贡献者和我们最终知道我们的流程是什么以及我们如何处理事情。此外，我们应该设置 CI，以便测试 Open Saas。很可能我们会想要…