ICU流程和程序

ICU版本号政策

ICU版本号由最多四位数字组成，由点分隔。

    • 前两位数字用于主要版本号。C和J的主要版本号始终保持同步。

      • 第二位的偶数表示正式发布（例如4.2）

      • 第二位的奇数表示下一个主要版本的开发版本（例如4.3.1）。

    • 官方版本号中的第三位数字表示适用于C和J的维护更新。

      • 仅当C和J有常见更改（如CLDR更新）时才增加。

      • 例如，CLDR 1.7.1变更整合到ICU4C 4.2.1和ICU4J 4.2.1中。

    • 开发版本号中的第三位数字表示里程碑

      • ICU4C 4.3.1->ICU4C4.4发展里程碑1

    • 官方版本号中的第四位数字表示仅适用于C或J的维护更新。

      • 例如，ICU4C 4.2.0.1解决了一些特定于平台的构建问题，而J中没有相应的更改。

票证生命周期

以下是描述ICU Trac票据、功能请求或错误报告的生命周期，从最初提交到实施和审查，再到发布。

功能建议和设计

    1. 必须在 icu设计邮件列表。

    2. 提案电子邮件本身必须包括：（参见 模板子页)

      1. 建议的（新的或更改的）API签名

      2. Trac票号

      3. 建议的API评审员

      4. 评论的截止日期（通常是提案后一周）。

    3. 如果主题复杂，提案中的背景信息可能会有所帮助。如果有很多信息，请写一个 设计文件.

    4. API签名必须在提交之前由某人审阅，并且审阅者必须回复帖子。

    5. 在ICU核心团队会议上，我们有一个定期议程项目来确认最近的API提案（在提交代码之前或之后）。在这里，我们确认有人审查了它，没有人反对。

    6. 在API冻结里程碑时或之前，发现新的/更改的API没有提案，将被撤回。

    7. 我们将尝试编写一个工具来查找添加的API。其思想是向存储库中添加一个文本文件，其中包含预期的添加/更改，并对照该文件检查实际的API集。

    8. 在API Slush里程碑之后，不应该有重大的API添加。小的添加（例如，现有类上的新方法）应该可以。

    9. 需要在分支上实现主要功能/新API或中断性更改。在将API合并到主干之前，必须对其进行审查和确认。

ICU编码风格指南

ICU编码指南在用户指南中进行了描述，网址为 http://icu-project.org/userguide/conventions.html

ICU放行流程

发布任务列表包含发布新版本ICU库时要完成的事项列表。

设计文件

各种ICU服务的设计文件保存在以下位置：