维护

一生中一个小版本,新版本(补丁版本)每月发表。本文档描述了可接受的边界变化。

错误修复被接受在下列条件:

• 这种变化不会破坏有效的单元测试;
• 新的单元测试覆盖错误修正;
• 当前车的行为并没有受到广泛用作“特性”。

为了避免向后兼容性优惠,我们往往是非常严格的关于改变接受补丁版本。

除了bug修复,其他一些小的更改可能会接受一个补丁版本基础上,根据实际情况:

• 新版本的PHP:修复添加对新版本的PHP的支持是可以接受的,如果他们不打破单元测试套件,但我们从来没有添加支持新的PHP功能;
• 流行的操作系统的新版本:修复添加对新版本的支持流行的操作系统(Linux, MacOS和Windows)是可以接受的,如果他们不打破单元测试套件,但是我们从来没有添加支持新的PHP功能或操作系统的新版本;
• 翻译:翻译更新和添加总是在最古老的维护分支合并;
• 外部数据:更新外部数据包含在Symfony可以更新(例如像ICU);ob娱乐下载
• 版本更新为作曲家依赖关系:改变最小版本的依赖是可能的,撞到一个主要或增加PHP版本不是最小;
• 测试:增加可以添加代码覆盖率的测试。

以下的变化一般不接受在一个补丁版本中,除了基础上,根据实际情况(主要是当这个有关解决安全问题):

• 性能改进:性能改进应该只接受如果更改本地(位于一个类),只有算法问题(任何这样的补丁必须要有数字显示真实的代码)的一个重大进步;
• 编码标准和重构:编码标准修复或代码重构几乎从未接受过除了与现有代码库的一致性,如果他们不太入侵,如果合并成更高的分支机构将不会导致复杂的分支合并。
• 添加新类或非私有方法:当在一个bug修复工作,从来没有引入新的类或公共/保护方法(或全局函数)。
• 添加配置选项:引入新的配置选项是不允许的。
• 添加新用法:一个版本达到稳定后,无法添加新用法了。

上面列出的任何没有明确应该做或大或小的下一个版本。例如,从未接受过以下修改补丁版本:

• 新功能;
• 安全性加强;
• 向后兼容性休息:注意,向后兼容性可以解决安全问题,如果它不可能解决否则;
• 支持外部平台:添加支持新的平台(如Google App Engine)不能完成补丁版本;
• 异常消息:异常消息不能改变一些自动化系统可能会依靠他们(即使这不是推荐);
• 添加新的作曲家依赖关系;
• 支持新的主要版本的作曲家依赖关系:考虑支持现有的较新版本的依赖是不可接受的。
• 网页设计:改变内置的网页设计页面像例外,工具栏或分析器是不允许的。