按照 Kotlin 设计团队的表述（来源）：
“API 设计是刻在石上的，但这块石头相当柔软，经过一些努力，我们可以在以后重新塑造它。”
历史上，Apollo Kotlin每2到3年发布一个主要版本。这些版本通常包含需要专门迁移的大量更改。
从 Apollo Kotlin 4 开始，我们旨在实现更小、更迭代的更改，允许在必要时软性地重新塑造该 API 石头。
本文档强调了Apollo Kotlin 4以及其他Apollo Kotlin银河系项目的演化策略。
Apollo Kotlin项目遵循语义版本控制规范：
0.x.y版本的才是预发布版本4.0.0-alpha.x版本的才是alpha版本- alpha版本是功能版本，但没有API保证。
- 我们鼓励早期用户使用alpha版本，他们需要最新功能并对追踪API更改持开放态度。
4.0.0-beta.x版本的才是beta版本- Beta版本有文档和完整的测试套件。
- 我们鼓励在生产环境中使用beta版本。API可能会发生变化，但我们将尽力最小化更改的影响。
4.0.0-rc.x版本的才是发布候选版本- API已冻结，如果没有发现问题，则从其中生成一个稳定版本。
4.x.y版本的才是稳定发行版本- 稳定版本获得错误修复和新功能。
- 直到下一个主要版本之前，没有二进制中断性更改。
- 新主要版本发布后，将创建一个发布分支，以支持旧主要版本并修复错误和安全补丁。
我们对增量版本的更新采取宽松的解释。它们被用来暗示新功能或重大变更，但我们并不严格。一个小型的API新功能可能存在于修复版本的发布中。相反，一个重大的内部重写可能通过小型发布进行标志。
欢迎在任何版本上报告问题。
ⓘ 注意
有关不同中断性变更的更多信息，请参阅兼容性类型在Kotlin文档中。
二进制中断性更改仅在主要版本中发生。
我们尽可能避免在非主要版本中的源中断性更改。特别是，只在主要版本中发生参数名称更改和Error级别的弃用。
尽管如此，真正的100%源兼容性往往遥不可及，并且偶尔的非主要版本可能包含源中断性更改。
我们在几周后尝试将Kotlin版本更新到更新的版本。对于Kotlin版本n-1上的JVM消费者，这通常是一个兼容的变更，因为Kotlin JVM 尽可能保持n+1的向前兼容性。这可能会对非JVM消费者造成源破坏。在这些情况下，您需要在这几周内更新您的构建，或者继续使用更旧的Apollo Kotlin版本。
已编译的传递性库不受源破坏变更的影响。
错误修复发生在任何版本（修补版、小版本、大版本）。
其他变更将根据具体情况处理。在可能的情况下，我们将尝试使其触发源破坏变更为信号变化。
某个事物是错误修复还是另一种类型的变更 留待解释，我们将在那里尽量做出合理的选择。
标记为 @ApolloExperimental 的符号不属于公共API，因此可以随时更改。
标记为 @Deprecated 的符号在以下情况下会被移除：
- 发布了一个主要版本...
- 并且该符号至少被弃用了6个月。
理想状态下（但我们无法保证），我们将尝试提供一年更新窗口（6个月作为警告，6个月作为错误）。