语义化版本控制教程
Reference: https://semver.org/lang/zh-CN/
摘要 版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
主版本号：当你做了不兼容的 API 修改， 次版本号：当你做了向下兼容的功能性新增， 修订号：当你做了向下兼容的问题修正。 先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
简介 在软件管理的领域里存在着被称作“依赖地狱”的死亡之谷，系统规模越大，加入的包越多，你就越有可能在未来的某一天发现自己已深陷绝望之中。
在依赖高的系统中发布新版本包可能很快会成为噩梦。如果依赖关系过高，可能面临版本控制被锁死的风险（必须对每一个依赖包改版才能完成某次升级）。而如果依赖关系过于松散，又将无法避免版本的混乱（假设兼容于未来的多个版本已超出了合理数量）。当你项目的进展因为版本依赖被锁死或版本混乱变得不够简便和可靠，就意味着你正处于依赖地狱之中。
作为这个问题的解决方案之一，我提议用一组简单的规则及条件来约束版本号的配置和增长。这些规则是根据（但不局限于）已经被各种封闭、开放源码软件所广泛使用的惯例所设计。为了让这套理论运作，你必须先有定义好的公共 API。这可能包括文档或代码的强制要求。无论如何，这 套 API 的清楚明了是十分重要的。一旦你定义了公共 API，你就可以透过修改相应的版本号来向大家说明你的修改。考虑使用这样的版本号格式：X.Y.Z（主版本号.次版本号.修订号）修复问题但不影响 API 时，递增修订号；API 保持向下兼容的新增及修改时，递增次版本号；进行不向下兼容的修改时，递增主版本号。
我称这套系统为“语义化的版本控制”，在这套约定下，版本号及其更新方式包含了相邻版本间的底层代码和修改内容的信息。
语义化版本控制规范（SemVer） 以下关键词 MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、 RECOMMENDED、MAY、OPTIONAL 依照 RFC 2119 的叙述解读。
使用语义化版本控制的软件必须（MUST）定义公共 API。该 API 可以在代码中被定义或出现于严谨的文档内。无论何种形式都应该力求精确且完整。
标准的版本号必须（MUST）采用 X.Y.Z 的格式，其中 X、Y 和 Z 为非负的整数，且禁止（MUST NOT）在数字前方补零。X 是主版本号、Y 是次版本号、而 Z 为修订号。每个元素必须（MUST）以数值来递增。例如：1.9.1 -> 1.10.0 -> 1.11.0。
标记版本号的软件发行后，禁止（MUST NOT）改变该版本软件的内容。任何修改都必须（MUST）以新版本发行。
主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变。这样的公共 API 不应该被视为稳定版。
1.0.0 的版本号用于界定公共 API 的形成。这一版本之后所有的版本号更新都基于公共 API 及其修改内容。
修订号 Z（x.y.Z | x > 0）必须（MUST）在只做了向下兼容的修正时才递增。这里的修正指的是针对不正确结果而进行的内部修改。
次版本号 Y（x.Y.z | x > 0）必须（MUST）在有向下兼容的新功能出现时递增。在任何公共 API 的功能被标记为弃用时也必须（MUST）递增。也可以（MAY）在内部程序有大量新功能或改进被加入时递增，其中可以（MAY）包括修订级别的改变。每当次版本号递增时，修订号必须（MUST）归零。
主版本号 X（X.y.z | X > 0）必须（MUST）在有任何不兼容的修改被加入公共 API 时递增。其中可以（MAY）包括次版本号及修订级别的改变。每当主版本号递增时，次版本号和修订号必须（MUST）归零。
先行版本号可以（MAY）被标注在修订版之后，先加上一个连接号再加上一连串以句点分隔的标识符来修饰。标识符必须（MUST）由 ASCII 字母数字和连接号 [0-9A-Za-z-] 组成，且禁止（MUST NOT）留白。数字型的标识符禁止（MUST NOT）在前方补零。先行版的优先级低于相关联的标准版本。被标上先行版本号则表示这个版本并非稳定而且可能无法满足预期的兼容性需求。范例：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。
版本编译信息可以（MAY）被标注在修订版或先行版本号之后，先加上一个加号再加上一连串以句点分隔的标识符来修饰。标识符必须（MUST）由 ASCII 字母数字和连接号 [0-9A-Za-z-] 组成，且禁止（MUST NOT）留白。当判断版本的优先层级时，版本编译信息可（SHOULD）被忽略。因此当两个版本只有在版本编译信息有差别时，属于相同的优先层级。范例：1.0.0-alpha+001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85。
版本的优先层级指的是不同版本在排序时如何比较。
判断优先层级时，必须（MUST）把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较（版本编译信息不在这份比较的列表中）。
由左到右依序比较每个标识符，第一个差异值用来决定优先层级：主版本号、次版本号及修订号以数值比较。
例如：1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。
当主版本号、次版本号及修订号都相同时，改以优先层级比较低的先行版本号决定。
例如：1.0.0-alpha < 1.0.0。
有相同主版本号、次版本号及修订号的两个先行版本号，其优先层级必须（MUST）透过由左到右的每个被句点分隔的标识符来比较，直到找到一个差异值后决定：
只有数字的标识符以数值高低比较。
有字母或连接号时则逐字以 ASCII 的排序来比较。
数字的标识符比非数字的标识符优先层级低。
若开头的标识符都相同时，栏位比较多的先行版本号优先层级比较高。
例如：1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0。
为什么要使用语义化的版本控制？ 这并不是一个新的或者革命性的想法。实际上，你可能已经在做一些近似的事情了。问题在于只是“近似”还不够。如果没有某个正式的规范可循，版本号对于依赖的管理并无实质意义。将上述的想法命名并给予清楚的定义，让你对软件使用者传达意向变得容易。一旦这些意向变得清楚，弹性（但又不会太弹性）的依赖规范就能达成。
举个简单的例子就可以展示语义化的版本控制如何让依赖地狱成为过去。假设有个名为“救火车”的函数库，它需要另一个名为“梯子”并已经有使用语义化版本控制的包。当救火车创建时，梯子的版本号为 3.1.0。因为救火车使用了一些版本 3.1.0 所新增的功能，你可以放心地指定依赖于梯子的版本号大于等于 3.1.0 但小于 4.0.0。这样，当梯子版本 3.1.1 和 3.2.0 发布时，你可以将直接它们纳入你的包管理系统，因为它们能与原有依赖的软件兼容。
作为一位负责任的开发者，你理当确保每次包升级的运作与版本号的表述一致。现实世界是复杂的，我们除了提高警觉外能做的不多。你所能做的就是让语义化的版本控制为你提供一个健全的方式来发行以及升级包，而无需推出新的依赖包，节省你的时间及烦恼。
如果你对此认同，希望立即开始使用语义化版本控制，你只需声明你的函数库正在使用它并遵循这些规则就可以了。请在你的 README 文件中保留此页链接，让别人也知道这些规则并从中受益。
FAQ 在 0.y.z 初始开发阶段，我该如何进行版本控制？ 最简单的做法是以 0.1.0 作为你的初始化开发版本，并在后续的每次发行时递增次版本号。
如何判断发布 1.0.0 版本的时机？ 当你的软件被用于正式环境，它应该已经达到了 1.0.0 版。如果你已经有个稳定的 API 被使用者依赖，也会是 1.0.0 版。如果你很担心向下兼容的问题，也应该算是 1.0.0 版了。
这不会阻碍快速开发和迭代吗？ 主版本号为零的时候就是为了做快速开发。如果你每天都在改变 API，那么你应该仍在主版本号为零的阶段（0.y.z），或是正在下个主版本的独立开发分支中。
对于公共 API，若即使是最小但不向下兼容的改变都需要产生新的主版本号，岂不是很快就达到 42.0.0 版？ 这是开发的责任感和前瞻性的问题。不兼容的改变不应该轻易被加入到有许多依赖代码的软件中。升级所付出的代价可能是巨大的。要递增主版本号来发行不兼容的改版，意味着你必须为这些改变所带来的影响深思熟虑，并且评估所涉及的成本及效益比。
为整个公共 API 写文档太费事了！ 为供他人使用的软件编写适当的文档，是你作为一名专业开发者应尽的职责。保持项目高效的一个非常重要的部分是掌控软件的复杂度，如果没有人知道如何使用你的软件或不知道 哪些函数的调用是可靠的，要掌控复杂度会是困难的。长远来看，使用语义化版本控制以及对于公共 API 有良好规范的坚持，可以让每个人及每件事都运行顺畅。
万一不小心把一个不兼容的改版当成了次版本号发行了该怎么办？ 一旦发现自己破坏了语义化版本控制的规范，就要修正这个问题，并发行一个新的次版本号来更正这个问题并且恢复向下兼容。即使是这种情况，也不能去修改已发行的版本。可以的话，将有问题的版本号记录到文档中，告诉使用者问题所在，让他们能够意识到这是有问题的版本。
如果我更新了自己的依赖但没有改变公共 API 该怎么办？ 由于没有影响到公共 API，这可以被认定是兼容的。若某个软件和你的包有共同依赖，则它会有自己的依赖规范，作者也会告知可能的冲突。要判断改版是属于修订等级或是次版等级，是依据你更新的依赖关系是为了修复问题或是加入新功能。对于后者，我经常会预期伴随着更多的代码，这显然会是一个次版本号级别的递增。
如果我变更了公共 API 但无意中未遵循版本号的改动怎么办呢？（意即在修订等级的发布中，误将重大且不兼容的改变加到代码之中） 自行做最佳的判断。如果你有庞大的使用者群在依照公共 API 的意图而变更行为后会大受影响，那么最好做一次主版本的发布，即使严格来说这个修复仅是修订等级的发布。记住， 语义化的版本控制就是透过版本号的改变来传达意义。若这些改变对你的使用者是重要的，那就透过版本号来向他们说明。
我该如何处理即将弃用的功能？ 弃用现存的功能是软件开发中的家常便饭，也通常是向前发展所必须的。当你弃用部分公共 API 时，你应该做两件事：（1）更新你的文档让使用者知道这个改变，（2）在适当的时机将弃用的功能透过新的次版本号发布。在新的主版本完全移除弃用功能前，至少要有一个次版本包含这个弃用信息，这样使用者才能平顺地转移到新版 API。
语义化版本对于版本的字符串长度是否有限制呢？ 没有，请自行做适当的判断。举例来说，长到 255 个字符的版本已过度夸张。再者，特定的系统对于字符串长度可能会有他们自己的限制。
“v1.2.3” 是一个语义化版本号吗？ “v1.2.3” 并不是一个语义化的版本号。但是，在语义化版本号之前增加前缀 “v” 是用来表示版本号的常用做法。在版本控制系统中，将 “version” 缩写为 “v” 是很常见的。比如：git tag v1.2.3 -m "Release version 1.2.3" 中，“v1.2.3” 表示标签名称，而 “1.2.3” 是语义化版本号。
是否有推荐的正则表达式用以检查语义化版本号的正确性？ 有两个推荐的正则表达式。第一个用于支持按组名称提取的语言（PCRE[Perl 兼容正则表达式，比如 Perl、PHP 和 R]、Python 和 Go）。
参见：https://regex101.com/r/Ly7O1x/3/
语义化版本控制的规范是由 Gravatars 创办者兼 GitHub 共同创办者 Tom Preston-Werner 所建立。
如果您有任何建议，请到 GitHub 上提出您的问题。
参考流程
基础版本
假设我们正在开发一个名为 FireTrain 的函数库，该库用于处理火车调度相关的任务。项目从0.1.0版本开始，逐步添加功能、修复问题，最终达到稳定的1.0.0版本，并进一步发展到2.0.0版本。
版本迭代历史
| 版本号 | 发布说明 | 版本类型 |
|---|---|---|
| 0.1.0 | 初始开发版本，添加基本的火车调度功能。 | 初始版本 |
| 0.2.0 | 增加了列车时刻表管理功能，保持向下兼容。 | 次版本号递增 |
| 0.2.1 | 修复了时刻表管理模块中的一个小bug。 | 修订号递增 |
| 0.3.0 | 引入了车站管理功能，允许用户添加、删除和编辑车站信息。 | 次版本号递增 |
| 0.3.1 | 优化了车站搜索功能，提升查询速度。 | 修订号递增 |
| 0.4.0 | 增加了列车延误预测功能，基于历史数据进行简单预测。 | 次版本号递增 |
| 0.4.1 | 修复了延误预测模块中的数据解析错误。 | 修订号递增 |
| 0.5.0 | 添加了用户认证模块，允许不同权限的用户访问不同功能。 | 次版本号递增 |
| 0.5.1 | 修复了用户认证模块中的登录状态保持问题。 | 修订号递增 |
| 1.0.0 | 第一个稳定版本，完成了所有核心功能的开发，API稳定，不再进行重大更改。 | 主版本号递增 |
| 1.1.0 | 增加了报表生成功能，用户可以生成火车调度的各种统计报表。 | 次版本号递增 |
| 1.1.1 | 修复了报表生成模块中的格式错误问题。 | 修订号递增 |
| 1.2.0 | 引入了实时监控功能，支持实时查看火车运行状态。 | 次版本号递增 |
| 1.2.1 | 优化了实时监控的数据刷新机制，减少延迟。 | 修订号递增 |
| 2.0.0 | 进行重大架构重构，API发生不兼容的重大变化，提升系统性能和扩展性。 | 主版本号递增 |
详细迭代说明 0.1.0 初始版本 功能：实现基础的火车调度功能，如添加列车、安排运行时间等。 说明：处于开发初期，API和功能可能频繁变化。 0.2.0 增加时刻表管理 功能：添加了列车时刻表管理模块，允许用户创建和管理列车的运行时刻。 版本类型：次版本号递增，新增功能，向下兼容。 0.2.1 修复时刻表管理中的Bug 功能：修复了时刻表管理模块中的一个小bug，避免了时刻冲突。 版本类型：修订号递增，向下兼容的问题修正。 0.3.0 引入车站管理 功能：新增车站管理功能，用户可以添加、删除和编辑车站信息。 版本类型：次版本号递增，新增功能，向下兼容。 0.3.1 优化车站搜索 功能：提升车站搜索功能的性能，缩短查询时间。 版本类型：修订号递增，向下兼容的优化。 0.4.0 增加列车延误预测 功能：基于历史数据，添加简单的列车延误预测功能，帮助用户预判可能的延误情况。 版本类型：次版本号递增，新增功能，向下兼容。 0.4.1 修复延误预测数据解析 功能：修复了延误预测模块中的数据解析错误，确保预测结果准确。 版本类型：修订号递增，向下兼容的问题修正。 0.5.0 添加用户认证模块 功能：引入用户认证和权限管理，支持不同权限级别的用户访问不同功能模块。 版本类型：次版本号递增，新增功能，向下兼容。 0.5.1 修复用户认证状态 功能：解决了用户认证模块中登录状态保持的问题，提升用户体验。 版本类型：修订号递增，向下兼容的问题修正。 1.0.0 稳定版本 功能：完成所有核心功能的开发，API定义稳定，适用于生产环境。 版本类型：主版本号递增，重大稳定版本，不向下兼容的变化已停止。 1.1.0 增加报表生成功能 功能：用户可以生成各种火车调度的统计报表，如运行效率报表、延误分析报表等。 版本类型：次版本号递增，新增功能，向下兼容。 1.1.1 修复报表格式错误 功能：修复了报表生成模块中的格式错误，确保报表内容准确展示。 版本类型：修订号递增，向下兼容的问题修正。 1.2.0 引入实时监控 功能：新增实时监控功能，用户可以实时查看火车的运行状态和位置。 版本类型：次版本号递增，新增功能，向下兼容。 1.2.1 优化实时监控刷新机制 功能：优化了实时监控数据的刷新机制，减少数据延迟，提升实时性。 版本类型：修订号递增，向下兼容的优化。 2.0.0 重大架构重构 功能：对系统进行重大架构重构，API发生不兼容的改变，提升系统性能和扩展性，引入新的模块和服务。 版本类型：主版本号递增，包含不兼容的API修改。
更复杂的流程
假设我们正在开发一个名为 FireTrain 的函数库，该库用于处理火车调度相关的任务。项目从 0.1.0-alpha 版本开始，经过多个迭代阶段，最终达到稳定的 1.0.0 版本，并在后续版本中进行功能扩展和架构重构，最终发布 2.0.0 版本。
版本迭代历史
| 版本号 | 发布说明 | 版本类型 |
|---|---|---|
| 0.1.0-alpha.1 | 初始开发阶段，添加基础火车调度功能的初步实现。 | 先行版本（alpha） |
| 0.1.0-alpha.2 | 优化基础调度算法，修复部分初步实现中的Bug。 | 先行版本（alpha） |
| 0.1.0-beta.1 | 引入列车时刻表管理功能，进行初步测试。 | 先行版本（beta） |
| 0.1.0-beta.2 | 增强时刻表管理模块，添加用户界面优化。 | 先行版本（beta） |
| 0.1.0-rc.1 | 准备首个稳定发布，完成所有核心功能的内部测试。 | 候选发布（rc） |
| 0.1.0 | 第一个正式版本，发布基本的火车调度功能，适用于开发环境。 | 正式版本 |
| 0.2.0-alpha.1 | 增加车站管理功能的初步实现。 | 先行版本（alpha） |
| 0.2.0-beta.1 | 完善车站管理模块，进行功能测试。 | 先行版本（beta） |
| 0.2.0-rc.1 | 准备发布车站管理功能，完成综合测试。 | 候选发布（rc） |
| 0.2.0 | 发布车站管理功能，支持 添加、删除和编辑车站信息。 | 正式版本 |
| 0.3.0-alpha.1 | 引入列车延误预测功能的初步开发。 | 先行版本（alpha） |
| 0.3.0-beta.1 | 完善延误预测算法，进行功能验证。 | 先行版本（beta） |
| 0.3.0-rc.1 | 准备发布延误预测功能，完成系统集成测试。 | 候选发布（rc） |
| 0.3.0 | 发布列车延误预测功能，基于历史数据进行简单预测。 | 正式版本 |
| 1.0.0-alpha.1 | 重大功能整合及稳定性提升，开始向1.0.0迈进。 | 先行版本（alpha） |
| 1.0.0-beta.1 | 引入用户认证模块，进行功能测试和安全性评估。 | 先行版本（beta） |
| 1.0.0-rc.1 | 准备发布1.0.0版本，完成所有核心功能的综合测试。 | 候选发布（rc） |
| 1.0.0 | 第一个稳定版本，完成所有核心功能的开发，API稳定，适用于生产环境。 | 正式版本 |
| 1.1.0-alpha.1 | 增加报表生成功能的初步开发。 | 先行版本（alpha） |
| 1.1.0-beta.1 | 完善报表生成模块，进行功能和格式测试。 | 先行版本（beta） |
| 1.1.0-rc.1 | 准备发布报表生成功能，完成用户反馈整合。 | 候选发布（rc） |
| 1.1.0 | 发布报表生成功能，用户可以生成各种调度统计报表。 | 正式版本 |
| 1.2.0-alpha.1 | 引入实时监控功能的初步实现。 | 先行版本（alpha） |
| 1.2.0-beta.1 | 完善实时监控模块，优化数据刷新机制。 | 先行版本（beta） |
| 1.2.0-rc.1 | 准备发布实时监控功能，完成性能测试。 | 候选发布（rc） |
| 1.2.0 | 发布实时监控功能，支持实时查看火车运行状态 和位置。 | 正式版本 |
| 2.0.0-alpha.1 | 开始重大架构重构，提升系统性能和扩展性。 | 先行版本（alpha） |
| 2.0.0-beta.1 | 完成架构重构的主要部分，进行功能测试和兼容性验证。 | 先行版本（beta） |
| 2.0.0-rc.1 | 准备发布2.0.0版本，完成全面的系统集成和性能优化。 | 候选发布（rc） |
| 2.0.0 | 发布重大架构重构版本，API发生不兼容的重大变化，提升系统性能和扩展性。 | 正式版本 |
详细迭代说明 0.1.0-alpha.1 初始开发阶段 功能：实现基础的火车调度功能，如添加列车、安排运行时间等的初步版本。 说明：处于早期开发阶段，API和功能可能频繁变化，主要用于内部测试。 0.1.0-alpha.2 优化基础调度算法 功能：优化基础调度算法，提高系统响应速度，修复初步实现中的Bug。 说明：继续完善核心功能，增强系统稳定性。 0.1.0-beta.1 引入列车时刻表管理 功能：添加列车时刻表管理模块，允许用户创建和管理列车的运行时刻。 说明：进入beta测试阶段，开始外部测试，收集用户反馈。 0.1.0-beta.2 增强时刻表管理模块 功能：增强时刻表管理模块的用户界面，优化用户体验。 说明：根据beta测试反馈进行功能和界面的改进。 0.1.0-rc.1 准备首个正式发布 功能：完成所有核心功能的内部测试，准备发布第一个正式版本。 说明：进入候选发布阶段，进行最后的修复和优化。 0.1.0 初次正式发布 功能：发布基本的火车调度功能，适用于开发环境，供早期用户使用。 说明：第一个正式版本，标志着项目的初步稳定。 0.2.0-alpha.1 增加车站管理功能 功能：初步实现车站管理功能，允许用户添加、删除和编辑车站信息。 说明：开始开发新功能，进入alpha阶段。 0.2.0-beta.1 完善车站管理模块 功能：完善车站管理模块的功能，进行全面测试，确保模块稳定。 说明：进入beta测试阶段，邀请用户参与测试，反馈问题。 0.2.0-rc.1 准备发布车站管理功能 功能：完成车站管理功能的综合测试，修复所有已知问题。 说明：候选发布阶段，准备将新功能集成到正式版本中。 0.2.0 发布车站管理功能 功能：发布车站管理功能，支持用户进行车站信息的全面管理。 说明：正式版本发布，标志着项目功能的进一步完善。 0.3.0-alpha.1 引入列车延误预测 功能：开始开发基于历史数据的列车延误预测功能，提供初步预测结果。 说明：进入新的功能开发阶段，优化预测算法。 0.3.0-beta.1 完善延误预测算法 功能：完善延误预测算法，提升预测准确性，进行功能验证。 说明：进入beta测试阶段，确保功能可靠性。 0.3.0-rc.1 准备发布延误预测功能 功能：完成延误预测模块的系统集成测试，修复所有相关问题。 说明：候选发布阶段，准备将延误预测功能集成到正式版本中。 0.3.0 发布列车延误预测功能 功能：发布列车延误预测功能，帮助用户预判可能的延误情况。 说明：正式版本发布，增强了项目的预测分析能力。 1.0.0-alpha.1 开始向1.0.0迈进 功能：整合之前所有功能，进行稳定性提升，准备发布1.0.0版本。 说明：进入重大版本发布准备阶段，开始综合测试。 1.0.0-beta.1 引入用户认证模块 功能：添加用户认证和权限管理功能，支持不同权限级别的用户访问不同功能模块。 说明：进入beta测试阶段，确保认证模块的安全性和可靠性。 1.0.0-rc.1 准备发布1.0.0版本 功能：完成所有核心功能的综合测试和性能优化，确保系统稳定。 说明：候选发布阶段，准备发布第一个稳定的1.0.0版本。 1.0.0 第一个稳定版本 功能：完成所有核心功能的开发，API定义稳定，适用于生产环境。 说明：标志着项目进入稳定的发布阶段，适用于正式使用。 1.1.0-alpha.1 增加报表生成功能 功能：开始开发报表生成功能，允许用户生成各种调度统计报表。 说明：进入新功能开发阶段，提升数据分析能力。 1.1.0-beta.1 完善报表生成模块 功能：完善报表生成模块的功能，确保报表格式和数据准确性。 说明：进入beta测试阶段，收集用户反馈，修复问题。 1.1.0-rc.1 准备发布报表生成功能 功能：完成报表生成功能的系统集成测试，优化用户界面。 说明：候选发布阶段，准备将报表功能集成到正式版本中。 1.1.0 发布报表生成功能 功能：发布报表生成功能，用户可以生成各种火车调度的统计报表，如运行效率报表、延误分析报表等。 说明：正式版本发布，增强了数据分析和报告能力。 1.2.0-alpha.1 引入实时监控功能 功能：开始开发实时监控功能，允许用户实时查看火车的运行状态和位置。 说明：进入新功能开发阶段，提升系统的实时性和可视化能力。 1.2.0-beta.1 完善实时监控模块 功能：优化实时监控的数据刷新机制，减少延迟，确保数据实时性。 说明：进入beta测试阶段，进行功能和性能测试。 1.2.0-rc.1 准备发布实时监控功能 功能：完成实时监控模块的综合测试，修复所有已知问题，优化用户体验。 说明：候选发布阶段，准备将实时监控功能集成到正式版本中。 1.2.0 发布实时监控功能 功能：发布实时监控功能，用户可以实时查看火车的运行状态和位置，提升系统的实时管理能力。 说明：正式版本发布，增强了系统的实时监控能力。 2.0.0-alpha.1 开始重大架构重构 功能：启动系统架构重构项目，提升系统性能和扩展性，规划新的模块和服务。 说明：进入重大版本开发阶段，进行深度优化和功能扩展。 2.0.0-beta.1 完成架构重构的主要部分 功能：完成大部分架构重构工作，进行功能测试和兼容性验证，确保新架构的稳定性。 说明：进入beta测试阶段，进行全面的系统测试。 2.0.0-rc.1 准备发布2.0.0版本 功能：完成全面的系统集成和性能优化，修复所有相关问题，确保新架构的稳定性和性能。 说明：候选发布阶段，准备发布2.0.0版本。 2.0.0 发布重大架构重构版本 功能：发布2.0.0版本，进行重大架构重构，API发生不兼容的重大变化，提升系统性能和扩展性，引入新的模块和服务。 说明：正式版本发布，标志着项目进入全新的阶段，具备更强大的功能和更高的稳定性。