版本控制策略

从 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 中任何已文档化的公共类或接口,例如 ScalaDoc。我们努力确保发布版本之间的源代码兼容性和二进制兼容性。

然而请注意,即使对于“开发者 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 4.0 发布窗口

日期 活动
2025 年 1 月 15 日 代码冻结。发布分支创建。
2025 年 2 月 1 日 QA 阶段。重点关注错误修复、测试、稳定性和文档。通常不合并新功能。
2025 年 2 月 15 日 发布候选版本 (RC)、投票等,直至最终版本通过

维护版本和生命周期结束 (EOL)

特性发布分支通常会通过错误修复版本维护 18 个月。例如,自 2019 年 9 月(即 2018 年 2 月 2.3.0 发布后 18 个月),分支 2.3.x 不再被视为维护状态。在此之后,即使是错误修复,也不应再期望有 2.3.x 版本发布。

主版本中的最后一个次要版本通常会作为“LTS”版本维护更长时间。例如,3.5.0 于 2023 年 9 月 13 日发布,并将维护 31 个月,直至 2026 年 4 月 12 日。

最新消息

归档