版本控制

Ruff 使用一种自定义版本控制方案：使用次版本号表示破坏性变更，使用修订版本号表示错误修复。Ruff 目前尚未提供稳定的 API；一旦 Ruff 的 API 稳定，将使用主版本号并采用语义化版本控制。

版本变更

在以下情况下，次版本号会增加：

弃用的选项或功能被移除
配置发生不向后兼容的变更
- 在达到 1.0.0 之前，这种情况可能在次版本变更中发生，但通常应尽量避免。
对新文件类型的支持被提升为稳定版
对已停止支持（EOL）的 Python 版本的支持被移除
Linter（代码检查器）
- 规则被提升为稳定版
- 稳定规则的行为发生变更
  - 稳定规则的适用范围显著扩大
  - 规则的意图发生变更
  - 不包括遵循规则原有意图的错误修复
- 将稳定规则添加到默认集合中
- 从默认集合中移除稳定规则
- 规则的安全修复程序被提升为稳定版
- 规则被弃用
Formatter（格式化程序）
- 稳定样式发生变更
语言服务器
- 现有功能被移除
- 已弃用的服务器设置被移除

在以下情况下，修订版本号会增加：

错误被修复，包括修复错误的各种行为变更
以向后兼容的方式添加了新的配置选项（无格式变更或新的 lint 错误）
增加了对新 Python 版本的支持
在预览模式下增加了对新文件类型的支持
弃用了某个选项或功能
Linter（代码检查器）
- 添加了规则的不安全修复程序
- 在预览模式下添加了规则的安全修复程序
- 在预览模式下扩大了规则的适用范围
- 修复程序的适用性被降级
- 在预览模式下添加了规则
- 预览规则的行为发生变更
Formatter（格式化程序）
- 更改了稳定样式以防止无效语法、程序语义变更或注释丢失
- 预览样式发生变更
语言服务器
- 增加了对新功能的支持
- 添加了新的服务器设置
- 弃用了某个服务器设置

编译 Ruff 所需的最低 Rust 版本在 Cargo.toml 中 [workspace.package] 部分的 rust-version 键中列出。它可能会在任何版本（次版本或修订版本）中发生变化。它永远不会高于 N-2 个 Rust 版本，其中 N 是最新的稳定版本。例如，如果最新的稳定 Rust 版本是 1.85，那么 Ruff 的最低支持 Rust 版本最高为 1.83。

这仅与从源代码构建 Ruff 的用户相关。从 Python 包索引（PyPI）安装 Ruff 通常会安装预构建的二进制文件，不需要进行 Rust 编译。

预览模式

预览模式可用于启用新的、不稳定的规则和功能，例如对新文件类型的支持。

预览模式旨在帮助我们收集社区反馈，并确信相关变更能够带来净收益。

预览模式并非旨在作为未完成工作或我们很可能会移除的功能的门槛。然而，我们保留对该模式控制下的任何行为进行修改的权利，包括移除预览功能或规则。

规则稳定性

在修改或添加规则时，我们遵循以下准则：

新规则应始终以预览模式添加
新规则在提升为稳定版之前，至少会在预览模式下保留一个次版本发布周期
- 如果是在修订版本发布（例如 0.6.1）中添加的，那么该规则直到 0.8.0 才有资格进入稳定状态
稳定规则的行为不会在修订版本中发生重大变更
规则向稳定版的提升可能会被推迟，以便将其“批量”集中在单个次版本发布中
并非所有预览中的规则都需要在给定的次版本发布中被提升

修复稳定性

修复程序具有三个适用性级别：

显示 (Display)：从不自动应用，仅供显示。
不安全 (Unsafe)：可以通过明确选择加入来应用。
安全 (Safe)：可以自动应用。

规则的修复程序可能会以较低的适用性引入，随后提升到较高的适用性。降低修复程序的适用性不属于破坏性变更。当启用预览模式时，特定修复程序的适用性可能会发生变化。

Visual Studio Code 扩展

Visual Studio Code 不支持扩展的预发布标签。因此，Ruff 使用以下方案来区分稳定版本和预览版本：

稳定版本在次版本号组件中使用偶数：2024.30.0, 2024.32.0, 2024.34.0, …… 预览版本在次版本号组件中使用奇数：2024.31.0, 2024.33.0, 2024.35.0, ……