Apache Hadoop 发布版本控制

背景

Apache Hadoop 使用 <major>.<minor>.<maintenance> 的版本格式，其中每个版本组件都是一个数字值。版本还可以有额外的后缀，如 “-alpha2” 或 “-beta1”，表示 API 兼容性保证和发布的质量。我们使用 “a.b.c” 和 “x.y.z” 表示点分版本三元组。

主要版本用于引入重大、可能不兼容的更改。例如，在 Hadoop 2 中用 YARN 和 MapReduce 2 替换 MapReduce 1，以及在 Hadoop 3 中将所需的 Java 运行时版本从 JDK7 升级到 JDK8。

次要版本用于在主要版本中引入新的兼容功能。

维护版本包括错误修复或低风险的支持性更改。

Hadoop 的版本控制方案多年来一直在不断发展。从 0.20.2 到 1.y 版本的早期阶段出现了 大量并行发布，具有不同的功能集。发布活动在 2.y 版本的早期阶段合并，从 2.0.0 到 2.7.0 的版本发布基本呈线性发展。

然而，2.6.z 和 2.7.z 的持续维护重新引入了 Hadoop 的并行活动发布线。2.8.z 和 3.0.z 版本的其他计划意味着可能会有四条活动发布线，需要澄清 Hadoop 版本控制以及它如何影响这些并行发布分支。

版本控制规则

为了建立共同的知识基础，我们对发布版本有以下要求。

这意味着需要将新的主要版本与之前的次要版本进行协调。新的次要版本和维护版本只需要在其发布线内进行协调。

“-alphaX” 和 “-betaX” 后缀版本可以视为 a.b.c 版本，第一个（例如 “-alpha1”）是 a.b.0 版本。

在设置修复版本时，此策略由以下规则集编码

  1. 对于每个次要版本行，设置最低未发布的 a.b.c 版本，其中 c ≥ 0。
  2. 对于每个主要版本行，设置最低未发布的 a.b.0 版本。

示例

例如，截至 2016 年 8 月 3 日，2.6.x 和 2.7.x 行中的最新版本是 2.6.4 和 2.7.2。我们还为计划的未来版本剪切了以下分支：branch-2.7.3、branch-2.8 和 branch-3.0.0-alpha1。

如果我们提交一个针对 2.6.5 版本的错误修复，我们将提交到

  1. 主干 (3.0.0-alpha2)
  2. branch-3.0.0-alpha1 (3.0.0-alpha1)
  3. branch-2 (2.9.0)
  4. branch-2.8 (2.8.0)
  5. branch-2.7 (2.7.4)
  6. branch-2.7.3 (2.7.3)
  7. branch-2.6 (2.6.5)

应用上述设置修复版本的规则

  1. 规则 1：2.6.z 和 2.7.z 都是次要版本行，因此设置2.6.5和2.7.3
  2. 规则 2：2.y.z 和 3.y.z 是主要版本行，因此设置2.8.0和3.0.0-alpha1

请注意，在移植更改时，我们始终确保移植到版本行中下一个更高的版本。例如，我们在移植到 branch-2.7.3 (2.7.3) 时确保移植到 branch-2.7 (2.7.4)，并在移植到 branch-2.8 (2.8.0) 时确保移植到 branch-2 (2.9.0)。这保留了版本的单调性。