维护

在小版本的生命周期内，每个月都会发布新版本(补丁版本)。本文档描述了可接受更改的边界。

错误修复在以下条件下接受:

• 该更改不会破坏有效的单元测试;
• 新的单元测试涵盖了bug修复;
• 当前的bug行为并没有作为“特性”被广泛使用。

为了避免向后兼容性中断，我们倾向于对补丁版本所接受的更改非常严格。

除了bug修复外，在一个补丁版本中，可能会根据具体情况接受其他一些小的更改:

• 更新的PHP版本:如果不破坏单元测试套件，添加对新版本PHP的支持的修复是可以接受的，但我们从不添加对新PHP特性的支持;
• 流行操作系统的更新版本:在不破坏单元测试套件的情况下，添加对流行操作系统(Linux、MacOS和Windows)新版本支持的修复是可以接受的，但我们从不添加对较新的PHP特性或较新的操作系统版本的支持;
• 翻译:翻译更新和添加总是在最古老的维护分支中合并;
• 外部数据: Symfony中包含的外部数据可以更新(如ICU);欧宝娱乐app下载地址
• 针对Composer依赖项的版本更新:修改一个依赖的最小版本是可能的，但升级到一个主版本或增加PHP的最小版本是不可能的;
• 测试:可以添加增加代码覆盖率的测试。

以下更改为一般不接受在补丁版本中，除非是根据具体情况(主要是与修复安全问题有关):

• 性能改进:只有在局部(位于一个类中)且仅针对算法问题的情况下才能接受性能改进(任何此类补丁必须附带数字，以显示对实际代码的显著改进);
• 编码标准和重构:编码标准修复或代码重构几乎不被接受，除非它们与现有的代码库保持一致，前提是它们不是太有侵入性，并且将它们合并到更高的分支不会导致复杂的分支合并。
• 添加新的类或非私有方法:在修复bug时，永远不要引入新的类或公共/受保护的方法(或全局函数)。
• 添加配置选项:不允许引入新的配置选项。
• 添加新的弃用:当版本达到稳定后，不能再添加新的弃用。

上面没有明确列出的内容应该在下一个小版本或大版本中完成。例如，以下更改在补丁版本中永远不会被接受:

• 新功能；
• 安全性加强；
• 向后兼容性中断:请注意，如果无法通过其他方式修复安全问题，则可以在修复安全问题时进行向后兼容性破坏;
• 支持外部平台:在补丁版本中无法添加对新平台(如谷歌应用引擎)的支持;
• 异常消息:不可更改异常消息，因为一些自动化系统可能依赖于它们(即使不建议这样做);
• 添加新的Composer依赖项；
• 支持新版本的Composer依赖项:考虑对现有依赖项的更新版本的支持是不可接受的。
• 网页设计:不允许更改内置页面的网页设计，如异常，工具栏或分析器。