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 具有中版本的特征。自首次发布以来，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 通常将微版本用于功能发布，并将次版本用于重要的向后不兼容的更改）。
优点
SemVer 是众所周知的，并且通常是三位数版本控制情况下的假定模型。
SemVer 简洁地描述了每个版本的意图。
缺点:
SemVer 的兼容性保证在实践中难以实现。
SemVer 没有针对零版本的特殊情况，因此不是对 JAX 迄今为止的发布过程的良好描述。
日历版本控制#
另一种常见的版本控制方案是基于日历的版本控制 (CalVer)，通常也用三个数字 YEAR . MONTH . DAY 表示。根据设计，这些数字不包含有关所包含更改的任何语义含义，而是对软件发布时的日历数据进行编码。例如，2024.12.16 版本表示它反映了 2024 年 12 月 16 日主分支的状态。
优点
CalVer 立即传达了特定发布的时间戳，这在其他版本控制方案中可能难以确定。
缺点
CalVer 版本号不向用户提供有关其包含的更改严重程度的任何信号。