版本控制策略

从 Spark 1.0.0 开始,Spark 项目将遵循 语义化版本控制指南,但有一些偏差。这些小的差异是因为 Spark 作为一个多模块项目的性质。

Spark 版本

每个 Spark 版本都将进行版本控制:[主版本号].[特性版本号].[维护版本号]

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

Alpha 组件

当新的组件添加到 Spark 时,它们最初可能会被标记为“alpha”。Alpha 组件不必遵守上述准则,但是,在最大程度上,它们应该尝试这样做。一旦它们被标记为“stable”,它们就必须遵循这些准则。

API 兼容性

一般来说,API 是 Spark 中记录的任何公共类或接口,例如 ScalaDoc。我们尽量保证版本之间的源代码兼容性和二进制兼容性。

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

破坏 API 时的考虑因素

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

破坏 API 的成本

破坏 API 几乎总是会对 Spark 用户造成相当大的成本。破坏的 API 意味着需要重写 Spark 程序才能升级。但是,在考虑成本时,需要考虑以下几个因素

  • 使用情况 (Usage) - 在许多不同地方积极使用的 API 总是非常难以破坏。虽然很难确定使用情况,但有很多方法可以估计
    • 该 API 在 Spark 中存在了多久?

    • 即使对于基本程序,该 API 是否常见?

    • 我们多久在 JIRA 或邮件列表中看到最近的问题?

    • 它多久出现在 StackOverflow 或博客中?

  • 中断后的行为 (Behavior after the break) - 今天运行正常的程序在中断后会如何运行?以下大致按严重程度递增的顺序列出

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

    • 会出现运行时异常吗?

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

    • 我们会静默地返回不同的答案吗?(很难调试,甚至可能没有注意到!)

维护 API 的成本

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

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

  • 用户成本 (User Costs) - API 还会给学习 Spark 或尝试理解 Spark 程序的用户带来认知成本。当相关 API 具有令人困惑或未定义的语义时,这种成本会变得更高。

破坏 API 的替代方案

如果存在“Bad API”,但删除成本也很高,则应考虑不损害现有用户但解决部分维护成本的替代方案。

  • 避免使用 Bad API (Avoid Bad APIs) - 虽然这有点明显,但这是一个重要的观点。每当我们向 Spark 添加新接口时,我们都应该考虑到我们可能会永远被这个 API 困住。深入思考新 API 与现有 API 的关系,以及你期望它们如何随时间演变。

  • 弃用警告 (Deprecation Warnings) - 所有弃用警告都应指向明确的替代方案,而不应只是说 API 已弃用。

  • 更新的文档 (Updated Docs) - 文档应指向执行给定任务的“最佳”推荐方式。在我们维护旧版文档的情况下,我们应该清楚地指向较新的 API,并向用户建议“正确”的方式。

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

发布节奏

分支机构在每年的一月和七月切出,因此特性(“次要”)版本通常大约每 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 月起,分支 2.3.x 不再被视为已维护,即在 2018 年 2 月发布 2.3.0 后的 18 个月。在那之后,即使是错误修复也不应再期望发布 2.3.x 版本。

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

最新消息

存档