维护

在一个小版本的生命周期内，新版本（补丁版本）每月发布一次。本文档描述了可接受更改的范围。

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

• 更改不会破坏有效的单元测试；
• 新的单元测试覆盖了错误修复；
• 当前有缺陷的行为没有被广泛用作“功能”。

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

除了错误修复，其他小的更改可能会在个案基础上在补丁版本中被接受

• 更新版本的 PHP：如果修复没有破坏单元测试套件，则添加对更新版本 PHP 的支持的修复是可以接受的，但我们从不添加对更新 PHP 功能的支持；
• 更新版本的流行操作系统：如果修复没有破坏单元测试套件，则添加对更新版本的流行操作系统（Linux、MacOS 和 Windows）的支持的修复是可以接受的，但我们从不添加对更新 PHP 功能或更新版本操作系统 的支持；
• 翻译：翻译更新和添加始终合并到最旧的维护分支中；
• 外部数据：可以更新 Symfony 中包含的外部数据的更新（例如 ICU）；
• Composer 依赖项的版本更新：可以更改依赖项的最低版本，但不能升级到主要版本或提高 PHP 最低版本；
• 测试：可以添加增加代码覆盖率的测试。

以下更改通常不被接受在补丁版本中，除非在个案基础上（主要是在与修复安全问题相关时）

• 性能改进：只有当更改是局部的（位于一个类中）并且仅针对算法问题时，性能改进才应被接受（任何此类补丁都必须附带数字，这些数字显示了实际代码的显着改进）；
• 编码标准和重构：除了与现有代码库保持一致性之外，几乎从不接受编码标准修复或代码重构，如果它们不是太具侵入性，并且如果将它们合并到更高的分支中不会导致复杂的分支合并。
• 添加新类或非私有方法：在进行错误修复时，切勿引入新类或公共/受保护方法（或全局函数）。
• 添加配置选项：永远不允许引入新的配置选项。
• 添加新的弃用：在版本达到稳定后，不能再添加新的弃用。
• 添加或更新注解：不允许添加或更新注解（例如 PHPDoc 注解）；修复它们可能会被接受。

任何未在上面明确列出的内容都应在下一个小版本或主要版本中完成。例如，以下更改永远不会在补丁版本中接受

• 新功能;
• 安全加固;
• 向后兼容性中断：请注意，在修复安全问题时可以进行向后兼容性中断，如果无法以其他方式修复它；
• 支持外部平台：在补丁版本中不能完成添加对新平台（如 Google App Engine）的支持；
• 异常消息：不得更改异常消息，因为某些自动化系统可能依赖于它们（即使不建议这样做）；
• 添加新的 Composer 依赖项;
• 支持更新的主要版本的 Composer 依赖项：考虑支持现有依赖项的更新版本是不可接受的。
• 网页设计：不允许更改内置页面（如异常、工具栏或分析器）的网页设计。