JEP 25516：JAX 的基于工作量的版本控制#
本文档建议 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 具有 meso 版本的特性。 自首次发布以来，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 版本号不向用户提供任何关于其包含的更改的严重程度的信号。