接口稳定性

我们维护扩展 API 的首要任务就是高效的抽象和接口稳定性。对于用户来说，扩展不能经常性地无法工作，考虑到当前嘉立创 EDA 是一个快速发展的产品，这一点显得尤其正确且重要。

另一方面，我们还希望在快速提供新功能和保持向后兼容性之间取得适当的平衡，以下是我们打算如何做到这一点。

API 版本控制

对扩展 API 的更改将会被标识为 major.minor.patch。major 表示主要版本，minor 表示次要版本，patch 表示修正。

主要版本

INFO

嘉立创 EDA 专业版扩展 API 有自己的发布版本号，它并不等同于嘉立创 EDA 的版本号，一般来说，扩展 API 的主要更新会跟随嘉立创 EDA 的主要版本或次要版本发布。

对现有 API 的更改将作为主要版本提供，这些更改可能会对扩展产生明显的影响，并要求使用到这些 API 的扩展的作者更新其代码。

这包括对 API 本身的更改（例如：删除已经弃用的方法）或对 API 行为的更改。

扩展不会自动升级到这些版本，为了保持现有扩展的工作，嘉立创 EDA 专业版 API 开发团队承诺尽可能地延长已被弃用的方法的生命周期。

次要版本

新的 API 接口和错误修复将作为次要版本提供，只要将扩展运行在最新版本的嘉立创 EDA 中，这些新 API 将自动可供扩展使用。

如果 API 存在错误，我们可能会自行决定将错误修复作为次要更新发布，这取决于我们是否觉得某些扩展可能会因修复错误而损坏。虽然 API 行为的任何更改理论上都可能使扩展的工作不正常，但对于扩展作者和我们来说，将每个错误修复视为重大更改将产生很多不必要的额外开销。

修正

当我们修复了一个紧急的新问题，对 API 进行了微乎其微的变更，或者甚至只是修改了文档的内容后，我们会发布修正更新。

我们可能在修正更新中以中断的形式更改 API 的 TypeScript 类型定义。在 TypeScript 的世界里，Type 和 Script 是两个不同的东西。因此，对 Type 的更改不会影响现有代码，也不会导致已发布的扩展中断，拥有准确表示 API 最新状态的类型比具有完美的向后兼容性更重要，因为类型易于更新。通常，类型更改仅涉及重命名某些类型。

开发阶段的 API

开发阶段的 API 是仅当扩展被设置为开发版本时可用的 API，这允许扩展开发者尝试新的 API，并向嘉立创 EDA 专业版扩展 API 开发团队提供反馈，了解 API 是否满足使用需求，和/或以任何意想不到的方式运行。处于开发阶段的 API 在文档内将会有显著的标识。