JEP 25516：JAX 的基于工作量的版本控制#
本提案已于 0.5.0 版本起采纳。
本文档提议 JAX 核心库应明确采用**基于工作量的版本控制 (EffVer)** 来管理过去和未来的版本发布。这种版本控制方案在 EffVer：根据升级所需工作量来管理代码版本 中有更详细的描述。
以下章节将讨论支持此方法的考虑因素。
EffVer 的主要特性#
基于工作量的版本控制是一种三段式版本控制系统，类似于更广为人知的语义化版本控制 (SemVer)。它使用 **MACRO** . **MESO** . **MICRO** 形式的三段式版本号，其中版本号的递增基于适应更改所需的*预期工作量*。
例如，考虑当前版本为 2.3.4 的软件。
增加 **micro** 版本（即发布
2.3.5）向用户表明，他们无需或只需极少工作即可适应这些更改。增加 **meso** 版本（即发布
2.4.0）向用户表明，现有代码需要进行一些小的修改才能与这些更改兼容。增加 **macro** 版本（即发布
3.0.0）向用户表明，更新到这些更改可能需要付出显著的努力。
在某些方面，这抓住了更常用语义化版本控制的精髓，但避免了实践中难以兑现的兼容性保证的表述。
零版本#
此外，EffVer 赋予零版本特殊含义。软件的早期版本通常是 0.X.Y 形式，在这种情况下，X 具有宏版本的特性，而 Y 具有中版本的特性。JAX 自初始发布以来一直处于零版本状态（截至本文撰写时版本为 0.4.37），EffVer 的零版本情况很好地*事后*描述了 JAX 迄今为止发布版本背后的隐含意图。
在 EffVer 中，当实践中达到一定程度的稳定性时，建议从 0.X.Y 提升到 1.0.0 版本。
如果你的版本长时间停留在
0.9.x，这是一个很好的信号，表明事情已经相当稳定，是时候切换到1.0.0版本了。
优点
EffVer 简洁地传达了变更的意图，同时避免了在实践中难以遵守的兼容性保证。
EffVer 通过对零版本的特殊处理，正确描述了本提案之前 JAX 的发布策略。
EffVer 为如何考虑 JAX 1.0 提供了具体的建议。
缺点
EffVer 不如 SemVer 广为人知，也不如 CalVer 那样一目了然，因此可能会给用户带来一些困惑。
考虑的替代方案#
我们考虑了一些 EffVer 的替代方案，如下所述。在每种情况下，与 EffVer 相比，我们认为缺点大于优点。
非语义化版本控制（现状）#
JAX 当前的版本控制使用三个数字，除了简单的可排序性（即版本随时间递增）之外，没有正式的语义含义。实际上，JAX 迄今为止的版本号在语义上与 EffVer 的零版本情况非常相似。
一个选择是明确地将这种非语义化版本控制形式化。
优点
现状无需开发团队采取任何行动。
缺点
现状已导致用户困惑，他们期望 SemVer 的保证能够适用。
现状对那些希望 JAX 版本发布具有清晰意义信号的用户不友好。
语义化版本控制#
一个常见的替代方案是语义化版本控制 (SemVer)。SemVer 也用三个数字来编码版本，即：**MAJOR** . **MINOR** . **MICRO**。考虑当前版本为 2.3.4 的软件。
增加 **micro** 版本（即发布
2.3.5）表明该版本仅包含错误修复。增加 **minor** 版本（即发布
2.4.0）表明该版本包含错误修复以及新功能。增加 **major** 版本（即发布
3.0.0）表明该版本包含错误修复、新功能以及破坏性更改。
SemVer 没有对零版本进行特殊处理，这意味着 JAX 的现有版本违反了该版本控制方案的保证（在此之前，JAX 通常将 micro 版本用于功能发布，将 minor 版本用于重大的向后不兼容更改）。
优点
SemVer 广为人知，通常是三段式版本控制的默认模型。
SemVer 简洁地描述了每个版本的意图。
缺点:
SemVer 的兼容性保证在实践中难以实现。
SemVer 没有对零版本进行特殊处理，因此它不能很好地描述 JAX 迄今为止的发布流程。
日历版本控制#
另一种常见的版本控制方案是基于日历的版本控制 (CalVer)，通常也由三个数字表示：**YEAR** . **MONTH** . **DAY**。根据设计，这些数字不包含有关所含更改的任何语义含义，而是编码了软件发布的日历数据。例如，2024.12.16 版本表明它反映了 2024 年 12 月 16 日主分支的状态。
优点
CalVer 立即传达了特定版本的发布时间戳，这在其他版本控制方案中可能难以确定。
缺点
CalVer 版本号不会向用户提供关于其所含更改严重程度的任何信号。