向后兼容性

OpenZeppelin Contracts 使用语义化版本控制来传达其 API 和存储布局的向后兼容性。补丁和次要更新通常是向后兼容的，但极少数情况下会有例外，如下所述。主要更新应被假定为与之前的版本不兼容。在此页面上，我们提供有关这些保证的详细信息。

请记住，在发布版本时，我们根据语义化版本控制将次要版本视为主要版本，将补丁版本视为次要版本。这意味着 v2.1.0 可能会向 v3.0.0-alpha.0 添加功能，而 v3.0.0 将被视为一个破坏性版本。

API

在向后兼容的版本中，所有更改都应该是内部实现细节的添加或修改。大多数代码应该继续编译并按预期运行。此规则的例外情况如下所列。

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

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

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

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

如果出现破坏“升级兼容性”的情况，则会在变更日志中添加一个条目，列出这些破坏性更改。

补丁更新将始终保留存储布局兼容性，并且在 v3.0.0-alpha.0 之后，次要版本也将保留。这意味着一个已上线的合约可以从一个次要版本升级到另一个次要版本，而不会破坏存储布局。在某些情况下，在升级时可能需要初始化新的状态变量，尽管我们预计这种情况不会经常发生。

编译合约所需的最低 Cairo 版本在补丁更新中将保持不变，但在次要更新中可能会发生变化。