版本控制
版本变更
Polars 遵循 语义化版本控制规范
- 破坏性变更会导致主版本号增加（
1.0.0,2.0.0, ...） - 新功能和性能改进会导致次版本号增加（
1.1.0,1.2.0, ...） - 其他变更会导致修订版本号增加（
1.0.1,1.0.2, ...）
破坏性变更策略
Polars 非常重视向后兼容性，但如果某项变更能够带来更好的产品，我们也不会犹豫。
理念
我们并非总能一次性做到完美。我们边做边学，并听取用户的反馈。有时，我们过于急切地推出新功能，而没有充分考虑所有可能的影响。
如果发生这种情况，我们会纠正错误并引入破坏性变更。大多数时候，这并非大问题。用户会收到弃用警告，他们在代码库中快速进行搜索和替换即可。
有时，我们遇到的问题需要用户付出更多努力来修复。查询引擎的变更可能会严重影响数据管道中的假设。我们不会轻易进行此类变更，但如果我们相信它能使 Polars 变得更好，我们就会这样做。
摆脱过去的错误对于 Polars 的持续发展至关重要。我们知道用户需要花费时间和精力来跟进新版本，但最终，Polars 成为最好的产品会造福所有人。
何为破坏性变更
当公共 API 的现有组件被更改或移除时，就会发生破坏性变更。
如果某个功能在 API 参考文档中有所记载，则它属于公共 API 的一部分。
破坏性变更示例
- 弃用的函数或方法被移除。
- 参数的默认值被更改。
- 由于查询引擎的变更，查询结果发生变化。
不被视为破坏性变更的示例
- 未文档化的函数被移除。
- 公共类的模块路径被更改。
- 现有方法添加了一个可选参数。
错误修复不被视为破坏性变更，即使它可能影响某些用户的 工作流程。
不稳定功能
公共 API 的某些部分被标记为不稳定。您可以通过 API 参考文档中的警告，或者当配置选项 warn_unstable 激活时发出的警告来识别此功能。功能被标记为不稳定的原因有以下几点：
- 我们不确定确切的 API。名称、函数签名或实现将来可能会更改。
- 该功能尚未经过广泛测试。在实际场景中使用时可能会出现错误。
- 该功能尚未与完整的 Polars API 良好集成。您可能会发现在某个上下文中它能正常工作，但在另一个上下文中则不能。
以不稳定的形式发布功能使我们能够从在实际场景中使用 Polars 的用户那里收集重要反馈。这有助于我们在最终批准之前进行微调。只对稳定、经过充分测试的功能感兴趣的用户可以避免使用 API 的这一部分。
标记为不稳定的功能可能随时更改，而不会被视为破坏性变更。
弃用警告
如果我们决定引入破坏性变更，现有行为将在可能的情况下被弃用。例如，如果我们选择重命名一个函数，新函数将与旧函数一起添加，并且使用旧函数将导致弃用警告。
并非所有变更都能很好地弃用。查询引擎的变更可能对 API 的大部分产生影响。此类变更将不会发出警告，但会包含在变更日志和迁移指南中。
警告
Rust API 的破坏性变更不会首先被弃用，但会在变更日志中列出。目前，支持弃用功能会严重减缓开发速度。
弃用期
通常，弃用功能会在弃用发生后的两个破坏性发布版本后被移除。例如，在版本 1.2.3 中弃用的函数将在版本 2.0.0 中保留，并在版本 3.0.0 中移除。
此规则的一个例外是随破坏性发布版本引入的弃用。这些弃用将在下一个破坏性发布版本中强制执行。例如，在版本 2.0.0 中弃用的函数将在版本 3.0.0 中移除。
这意味着如果您的程序没有发出任何弃用警告，那么升级到下一个主版本应该大致是安全的。由于破坏性发布版本大约每六个月发布一次，这为您提供了六到十二个月的时间来适应任何待处理的破坏性变更。
在某些情况下，我们可能会决定调整弃用期。 如果保留弃用功能阻碍了 Polars 的其他改进，我们可能会将弃用期缩短为一个破坏性发布版本。这将在警告消息中提及。如果弃用影响到许多用户，我们可能会延长弃用期。
发布频率
Polars 没有固定的发布时间表。每当我们觉得有新的、有价值的东西可以提供给用户时，我们就会发布新版本。实际上，新的次要版本大约每两周发布一次。
预发布版本
为了最大程度地降低回归风险，我们首先发布一个预发布版本。接着是一个为期几天的冷却期，在此期间我们会阻止可能引入不稳定性的拉取请求。在此期间报告的任何回归错误更有可能在最终发布前得到解决。我们鼓励用户积极测试预发布版本，以帮助确保更高的稳定性。
破坏性发布版本
随着时间的推移，会出现需要破坏性变更才能解决的问题。当积累了足够多的问题时，我们就会发布一个破坏性版本。
迄今为止，破坏性发布版本大约每三到六个月发布一次。随着 Polars 变得更加稳定，破坏性变更的频率和严重性将继续降低。从现在开始，我们预计新的主版本大约每六个月发布一次。