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 version）的特性，而 Y 具有中间版本（meso version）的特性。自初始发布以来，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 相比，缺点都被认为 outweighs 优点。
非语义版本控制（现状）#
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 版本号没有向用户提供有关其包含的更改严重程度的信号。