语义版本控制 - 传统 Web 应用程序的主要版本答案

【问题标题】：Semantic versioning - major version for a traditional web application语义版本控制 - 传统 Web 应用程序的主要版本
【发布时间】：2020-08-04 22:48:57
【问题描述】：

我有一个 Rails 应用程序，它是一个传统的 Web 应用程序（处理 HTTP 请求并呈现 HTML 页面）。截至目前，它没有向其他应用程序公开的 API。

我想使用semantic versioning 对应用程序进行版本控制。目前它在'0.0.0'。

引用文档：

当您进行不兼容的 API 更改时的主要版本，
以向后兼容的方式添加功能时的次要版本，并且
进行向后兼容的错误修复时的 PATCH 版本。

据我了解，因为没有依赖于我的应用程序，所以主版本永远不会改变。只有次要版本和补丁版本会发生变化，主要版本将始终保持为 0。

我想知道我的理解是否正确。我的主要版本是否会发生变化？

【问题讨论】：

为什么要使用版本控制？（您是在向用户分发应用程序的副本，还是在不同的环境中安装了不同的版本，或者什么 - 语义版本控制可能不符合您的需求）
是的，我已经将它部署在不同的环境中——产品、演示和测试。我希望能够在不同的环境中识别软件的版本，否则可能会令人困惑。最终，我还将开发可供移动应用程序使用的 API。

标签： semantic-versioning

【解决方案1】：

您可以考虑的一种方法是将用户通过应用程序的流程视为版本控制的基础。如果发生破坏性更改（即用户的流程以一种使旧路线不可能的方式发生变化），那么它可以被认为是破坏性的。如果您要添加以前不存在的新功能（即用户可以访问新功能或在网站上看到可以与之交互的新内容），那么这可能被视为次要版本增加。如果您正在为文本等内容部署较小的修复，则可以将其视为补丁级别的更改。

不过，这种方法的问题在于，您需要通过应用程序了解用户的工作流程，才能正确地增加主要版本，而作为软件开发人员，我们在正确地做到这一点方面仍然非常糟糕。

参考：https://christianlydemann.com/versioning-your-angular-app-automatically-with-standard-version

【讨论】：

【解决方案2】：

由于您不是在开发和发布软件包，因此语义版本控制不直接适用。听起来单个“发布”号对于您的用例就足够了，因为您需要跟踪代码更改何时将在测试和生产中进行。假设代码在进入 prod 之前必须经过测试，那么每当您使用开发分支中的代码更新测试环境时，您都会更新数字。这样，在给定的时刻，开发会发布 N，测试会发布 N-1，而生产会发布 N-2。

API 版本控制是一个不同的问题，与版本编号无关。根据我的经验，API 用户只关心重大更改，因此需要对这些更改进行版本控制。此外，由于用户更新他们的应用程序的速度很慢，因此您必须准备好无限期地保留旧版本。

【讨论】：