版本策略

从 Spark 1.0.0 开始，Spark 项目将遵循 语义版本控制指南，并有一些偏差。这些细微的差异解释了 Spark 作为多模块项目的本质。

Spark 版本

每个 Spark 版本都将被版本化：[MAJOR].[FEATURE].[MAINTENANCE]

• MAJOR：所有具有相同主版本号的版本都将具有 API 兼容性。主版本号将在很长一段时间内保持稳定。例如，1.X.Y 可能持续 1 年或更长时间。
• FEATURE：功能版本通常包含新功能、改进和错误修复。每个功能版本都将有一个合并窗口，在此窗口中可以合并新的补丁，一个 QA 窗口，在此窗口中只能合并修复，然后是一个最终阶段，在此阶段对候选版本进行投票。这些窗口将在前一个功能版本发布后立即宣布，以便人们有充足的时间，并且随着时间的推移，我们可能会使整个发布过程更加规律（类似于 Ubuntu）。
• MAINTENANCE：维护版本将更频繁地出现，并取决于引入的特定补丁（例如错误修复）及其紧急程度。通常，这些版本旨在修复错误。但是，更高层的库可能会引入一些小功能，例如新算法，前提是这些功能是完全增量的，并且与现有代码路径隔离。Spark 核心可能不会引入任何功能。

Alpha 组件

当向 Spark 添加新组件时，它们最初可能会被标记为“alpha”。Alpha 组件不必遵守上述指南，但是，在最大程度上，它们应该尝试遵守。一旦它们被标记为“稳定”，它们就必须遵循这些指南。

API 兼容性

API 是 Spark 中公开的任何公共类或接口，未标记为“开发者 API”或“实验性”。如果针对版本 A 编译的代码可以干净地针对版本 B 编译，则版本 A 与版本 B 兼容。目前，不保证针对版本 A 链接的已编译应用程序可以在不重新编译的情况下干净地针对版本 B 链接。链接级兼容性是我们将在未来版本中努力保证的内容。

但是，请注意，即使对于“开发者 API”和“实验性”功能，我们也努力保持最大兼容性。如果计划稍后更改 API，则不应将代码作为“实验性”合并到项目中，因为用户期望所有可用 API 具有最大兼容性。

破坏 API 时需要考虑的因素

Spark 项目努力避免破坏 API 或静默更改行为，即使在主要版本中也是如此。虽然这并不总是可行，但在选择破坏 API 之前，应考虑以下因素的平衡。

破坏 API 的成本

破坏 API 几乎总是会给 Spark 用户带来非凡的成本。破坏的 API 意味着 Spark 程序需要在升级之前重写。但是，在考虑成本时，有一些需要考虑的因素

• 使用情况 - 在许多不同地方积极使用的 API 总是非常昂贵。虽然很难确定使用情况，但我们可以通过多种方式进行估计

  • API 在 Spark 中存在了多长时间？

  • 即使对于基本程序，API 是否也很常见？

  • 我们在 JIRA 或邮件列表中看到最近问题的频率如何？

  • 它在 StackOverflow 或博客中出现的频率如何？

• 破坏后的行为 - 今天有效的程序在破坏后将如何工作？以下是按严重程度递增的顺序排列的

  • 会出现编译器或链接器错误吗？

  • 会出现运行时异常吗？

  • 该异常是否会在完成大量处理后发生？

  • 我们会静默返回不同的答案吗？（非常难以调试，甚至可能不会注意到！）

维护 API 的成本

当然，以上并不意味着我们永远不会破坏任何 API。我们还必须考虑对项目和用户保持所讨论 API 的成本。

• 项目成本 - 我们拥有的每个 API 都需要进行测试，并且需要随着项目的其他部分发生变化而保持工作状态。当外部依赖项发生变化（JVM、Scala 等）时，这些成本会大大增加。在某些情况下，虽然在技术上并非完全不可行，但维护特定 API 的成本可能会变得过高。

• 用户成本 - API 对学习 Spark 或尝试理解 Spark 程序的用户也具有认知成本。当所讨论的 API 具有令人困惑或未定义的语义时，这种成本会更高。

破坏 API 的替代方案

在存在“不良 API”但移除成本也很高的情况下，应该考虑一些替代方案，这些方案不会损害现有用户，但确实可以解决一些维护成本。

• 避免不良 API - 虽然这有点明显，但这是一个重要的观点。每当我们向 Spark 添加新接口时，我们都应该考虑我们可能永远无法摆脱这个 API。深入思考新 API 与现有 API 的关系，以及您期望它们如何随着时间的推移而发展。

• 弃用警告 - 所有弃用警告都应该指向明确的替代方案，并且永远不应该仅仅说 API 已被弃用。

• 更新的文档 - 文档应该指向执行给定任务的“最佳”推荐方法。在维护旧文档的情况下，我们应该明确指向较新的 API，并向用户建议“正确”的方法。

• 社区工作 - 许多人通过阅读博客和其他网站（如 StackOverflow）来学习 Spark。但是，许多这些资源已经过时。更新它们，以降低最终移除弃用 API 的成本。

发布节奏

分支每年 1 月和 7 月被切断，因此功能（“次要”）版本通常每 6 个月发布一次。因此，Spark 2.3.0 通常会在 2.2.0 发布大约 6 个月后发布。维护版本根据需要在功能版本之间发布。主要版本没有按照固定时间表发布。

Spark 3.5 发布窗口

日期	活动
2023 年 7 月 16 日	代码冻结。发布分支切断。
2023 年 7 月下旬	QA 阶段。专注于错误修复、测试、稳定性和文档。通常，不会合并新功能。
2023 年 8 月	发布候选版本 (RC)、投票等，直到最终版本通过

维护版本和 EOL

功能发布分支通常会使用错误修复版本维护 18 个月。例如，分支 2.3.x 从 2019 年 9 月开始不再被视为维护，这是 2018 年 2 月发布 2.3.0 18 个月后。在那之后，不应该再期望出现 2.3.x 版本，即使是错误修复也是如此。

主要版本中的最后一个次要版本通常会作为“LTS”版本维护更长时间。例如，2.4.0 于 2018 年 11 月 2 日发布，并一直维护了 31 个月，直到 2021 年 5 月发布 2.4.8。2.4.8 是最后一个版本，即使是错误修复，也不应该再期望出现 2.4.x 版本。