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 具有 macro 版本的特征，而 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 版本号不向用户提供关于其包含的更改严重程度的任何信号。