稳定的发布政策

1 简介

本文件的目的是为 KiCad 项目提供创建版本的指南。

本文件适用于 6.0.0 版本之后的所有稳定版本。

未经项目负责人同意，请勿修改本文件。对本文件的所有修改都需要批准。

KiCad 使用典型的 [major].[minor].[bug fix] 版本划分方案。每个新版本都是前一版本的简单增量。新的主要版本将把次要版本和错误修复版本重置为 0。

在一个主要的发布周期内，不允许对电路板、原理图、封装库、符号库或工程文件格式进行修改，除非是修复已知的错误。

小版本和错误修复版本只对当前的稳定大版本有效。一旦新的稳定大版本发布，之前的稳定版本就被视为不再支持（弃用）的分支。

主要的发布将在每年的 1 月 31 日之前进行。这与每年的 FOSDEM 会议相一致。下表列出了发布时间表的日期。

Table 1. 主要发布时间表
日期	里程碑
2 月 1 日	新功能合并窗口打开。
9 月 30 日	新功能合并窗口关闭。仅修复错误的时期开始。
12 月 1 日	字符串冻结开始。
12 月 15 日	候选版本 RC1 被标记。
1 月 14 日	库、文件和，翻译库的冻结。错误修复冻结。
1 月 15 日	源代码库被标记为下一个主要版本并被分支。开始打包并上传到网站。
1 月 31 日	新版本发布公告。

在合并窗口关闭前没有准备好的功能将不得不等到下一个合并窗口。没有例外。

只有源代码库的分支是强制性的。如果开发团队认为有必要，所有其他仓库都会被分支。

只要满足以下条件，KiCad 当前开发分支的功能就可以回溯到当前稳定分支:

一个新的次要版本将包括当前错误修复版本中所包含的所有错误修复，因此对于新的次要版本发布，错误修复版本将被重置为 0。

开发分支的反向移植只能应用于当前的稳定分支。不允许向更早的稳定版本进行反向移植。

错误修复的发布是由主导开发团队决定的。

错误修复发布将由项目经理在发布前 30 天宣布，以便有时间完成所有必要的发布行动。

除了拼写和语法错误，错误修复不能包含可翻译的字符串变化。

错误修复只能应用于当前的稳定版。