向后兼容性

极少数情况下，补丁或次要更新会以破坏性的方式删除或更改 API，但前提是之前的 API 被认为是不安全的。这些重大更改将在变更日志和发行说明中注明，并与安全公告一起发布。

非最终版本的 ERC 可能会以不兼容的方式更改。因此，我们避免在 ERC 最终确定之前发布其实现。对于已经发布了很长时间并且似乎不太可能更改的 ERC，我们做了一些例外。可能存在重大更改的 ERC 的实现在名为 draft-*.sol 的文件中发布，以明确该条件。 对于带有 draft 前缀的文件中的内容，没有向后兼容性保证。

在社区中已实现广泛采用且具有强大的向后兼容性期望的标准，可以被视为事实上的最终版本，并在不带 draft- 前缀的情况下发布，因为广泛的生态系统依赖使得重大更改极不可能发生。

这个库中的几乎所有函数都是 virtual 的，但也存在一些例外，但这并不意味着鼓励重写。有一部分函数被设计为可以重写。通过在此子集之外定义重写，您可能会依赖内部实现细节。我们努力在这种情况下保持向后兼容性，但这非常困难并且很容易意外破坏。建议谨慎。

此外，一些次要更新可能会导致新的 "两个或多个基类定义了具有相同名称和参数类型的函数" 或 "需要指定重写的合约" 之类的编译错误，这是由于 Solidity 认为继承函数存在歧义。这应该通过添加一个经由 super 调用该函数的 override 来解决。

有关 virtual 和 override 的更多信息，请参阅 扩展合约。

带有下划线前缀的结构体成员应被视为“私有”，并且可能会在次要版本中中断。结构体数据应仅通过库函数访问和修改。

除非另有说明，否则不应假定 revert 中包含的特定错误格式和数据是稳定的。

主要版本应假定为不兼容。然而，如果合约的外部接口是标准化的，或者维护者认为更改它们会对生态系统造成重大压力，那么它们将保持兼容。

主要版本可能会破坏的一个重要方面是“升级兼容性”，特别是存储布局兼容性。从一个主要版本升级到另一个主要版本的活动合约永远是不安全的。