这份文档总结了进度和版本审查的目的和要求，以帮助那些不熟悉Eclipse基金会流程的团队成员进行定位。项目团队负责在版本周期内依照https://www.eclipse.org/projects/efsp/[Eclipse基金会规范过程]（EFSP）和项目当前的发布计划，执行适用的审查。

规范版本控制与发布周期

AsciiDoc语言规范使用语义版本控制。每个版本都以 主版本号.次版本号.修订号 的形式进行版本控制。

专业

主要版本发布（例如，1.0.0）发生在功能发生重大变化或者新功能破坏了向后兼容性时。

未成年

小版本更新（例如 1.1.0）会增加新功能、改进现有功能和修复错误，同时保持向后兼容性。

补丁Patch

补丁版本（例如，1.1.1）修复错误并对文档作出小的澄清，同时保持向后兼容性。 它们不包括新功能或破坏性更改。 补丁版本对应于Eclipse定义的[服务发布](https://www.eclipse.org/projects/efsp/#efsp-releases-service)。

里程碑构建

里程碑构建（例如，1.0.0-alpha.1、1.0.0-beta.3、1.0.0-rc.1）是一种预发布版本，意在供早期采用者进行测试。这不是最终发布版本，也不应作为正式或普遍使用而分发。在发布一个主要或次要版本之前，至少需要生产一个里程碑构建。

每一个主要和次要版本的规范都必须满足EFSP（Eclipse Foundation Specification Process）发布周期的计划和发布审核要求。一个主要或次要规范版本的发布周期从发布计划的批准开始。它以完成导致规范版本最终构建批准的发布审核及其构件的官方发布和分发结束。如果一个发布周期持续超过12个月没有发布或进度审查，项目团队必须产生一个里程碑构建并启动进度审查，以延长发布周期。

规范的修补版本（即[EFSP服务版本发布](https://www.eclipse.org/projects/efsp/#efsp-releases-service)）不需要一个独立的发布周期。它需要满足以下所有要求，才能被视为规范的修补版本发布：

  • 补丁版本必须符合补丁的范围。

  • 被修补的主要或次要版本必须已经完成了成功的发布审查。

  • 补丁版本必须完成自己的发布审核并成功通过，然后才能发布并供普遍使用。

请参阅EFPS以获取关于[规范版本发布周期](里程碑构建(https://www.eclipse.org/projects/efsp/#efsp-milestones)的完整描述。

1.0.0版本之前的版本控制

在为最终规范发布准备功能完备的里程碑版本之前，该项目会发布标记为_0.y.z_（例如，0.1.5, 0.2.0）的里程碑版本。这些版本是该项目标记并庆祝我们通向功能完备里程碑版本道路上成就的方式之一。

这些里程碑版本将使用一个在第一位的零（即0.y.z）。当规范或其TCK（测试兼容性工具包）增加一个重大特性时，_y_将递增（例如，0.3.0、0.4.0）。当构建只包含现有特性的改进、变更或修复时，_z_将递增（例如，0.3.2、0.4.1）。这些里程碑版本很可能会从一个版本到下一个版本包含破坏性更改，并且不会向后兼容。这些构建不是官方的，不适用于一般用途，也不应被视为功能完整。

项目团队一旦确定规范接近功能完整性，_0.y.z_的模式将不再使用。自此之后，所有未来的里程碑构建将使用语义化版本号，因为项目团队为发布规范的1.0.0版本做准备（例如，1.0.0-alpha.1）。本小节应在随后的发布周期开始时从文档中移除。

发布和进度审查

进展和发布审查描述了规范版本的主要变化，并提供了持久的工件，这些工件向社区、指导委员会、项目管理链（PMC）和Eclipse管理组织（EMO）展示这些变化，用于评估和反馈。发布审查对应于一个主要的、次要的或者补丁规范版本的最终构建，如果获得批准，就会被正式发布并广泛分发。如果进行了进展审查，它必须与规范版本的一个里程碑构建相匹配。

团队负责的审查工作

项目团队
项目负责人

  • 项目负责人有责任根据发布周期阶段、发布计划和EFPS要求，启动适当的审查。

  • 项目负责人负责管理计划中的审查，除非另有团队成员自愿协调。

发布审查要求

每个规范版本的主要发布、次要发布和补丁发布都必须进行发布审查。

  1. 一个项目负责人或团队成员自愿成为版本审查的审查协调员。

  2. 如果审查是针对主要或次要发布，审查协调员确认对于早期采用者而言，一个里程碑版本的构建至少提前14天已生产并可用，然后才能将该发布的最终构建版本进行分阶段处理。

  3. 如果审查是针对补丁发布的，审查协调人确认该补丁发布：

    1. 符合[补丁，补丁]的范围。

    2. 该主要或次要版本的发布已完成了一次成功的发布审查。

  4. 项目团队对规范版本的最终构建进行分阶段处理。这些构件必须为公开记录而持久保存，并且一旦审查过程开始就不能更改。

  5. 审查协调员汇编发布审查的文档。审查文档：

    1. 概述了规范版本的主要成就、变更以及移除/弃用的内容。

    2. 提供指向持久性工件的链接，或在交付时直接包含这些工件。

    3. 显示证据表明，规范版本的技术兼容性工具包（TCK）具有足够的覆盖率来自信地验证兼容的实现。

    4. 展示了证据，证明一个或多个兼容的实现满足了所有TCK（技术兼容性工具包）的要求和可选方面。

  6. 审查协调员将审查文件和材料交付给项目管理委员会（PMC），并要求启动一次审查。

  7. 当PMC批准了审查文件并同意审查可以继续进行后，审查协调员将审查文件和工件提交给EMO，并要求EMO安排审查。

  8. 评审协调员将评审文件和工件交付给指导委员会。

  9. 发行审查在获得EMO和指导委员会的批准时完成。

  10. 在发布审查顺利完成后，规范版本的成品就会发布供公众使用并进行分发。

Note
 这份文档仅关注进度和发布审查。还有其他类型的审查，例如[计划审查](重组审查(https://www.eclipse.org/projects/dev_process/#6_3_8_Restructuring_Review)。

进度审查要求

进度回顾可以在发布周期内自愿进行，团队认为合适时即可。只有当当前的发布周期持续了12个月没有发布或进度回顾时，才是必需的。进度回顾必须有一个里程碑构建来陪同。

  1. 项目负责人或团队成员志愿成为进度审查的审查协调员。

  2. 项目团队安排里程碑版本的工件。这些工件必须是持久的用于公共记录，并且一旦审查过程开始就不能改变。

  3. 审核协调员汇总进度审查的文档。审查文档包括：

    1. 简要描述自上次进展或发布审查以来已提交的主要更改。

    2. 列出任何在架构、功能、兼容性或性能上仍需解决的问题，以满足当前发布计划。

    3. 提供指向持久性工件的链接，或在交付时直接包含这些工件。

  4. 审查协调员将审查文件和材料交付给项目管理委员会（PMC），并要求启动一次审查。

  5. 当PMC批准了审查文件并同意审查可以继续进行后，审查协调员将审查文件和工件提交给EMO，并要求EMO安排审查。

  6. 评审协调员将评审文件和工件交付给指导委员会。

  7. 当它被EMO和指导委员会批准时，进度审查就完成了。

Warning
 进度审查不能与发布审查合并或重叠。

参考材料

这份文件的内容在很大程度上借鉴了Eclipse基金会发布的流程文档。上述各节列出的步骤是EFSP、Eclipse开发流程（EDP）和Eclipse手册中呈现的审查和发布周期信息的合并。具体来说，参见：

版本发布周期和版本控制
评论（流程概述）

  • 一般审查信息，如https://www.eclipse.org/projects/efsp/#efsp-reviews[EFSP]和https://www.eclipse.org/projects/handbook/#specification-project-reviews[手册]所述。

  • 关于https://www.eclipse.org/projects/handbook/#release-review[进展和发布审查（手册）]的概述。

发布评论

  • 根据https://www.eclipse.org/projects/efsp/#efsp-reviews-release[EFSP]、https://www.eclipse.org/projects/dev_process/#6_3_3_Release_Review[EDP]和https://www.eclipse.org/projects/handbook/#specifications-release-review[手册（针对规范）]所描述的，发布审查。

  • 关于[发布和审核记录（手册）](https://www.eclipse.org/projects/handbook/#pmi-releases)的更多信息。

进度评审

  • 进度审查如 EFSP、https://www.eclipse.org/projects/dev_process/#6_3_5_Progress_Review[EDP] 和 手册 所述。