跳至主要内容

版本控制

我们遵循 语义化版本控制 (semver)。本页旨在帮助设定关于我们认为属于每个 semver 类别的指南。

本项目中的所有包都发布了相同的版本号，以便更轻松地协调发布和安装。

重大变更​

在考虑是否将更改视为“重大”时，首先需要考虑它影响了哪些包。例如，解析器包的重大变更与 ESLint 插件的重大变更标准不同。这是因为它们不仅具有非常不同的 API 表面，而且还以非常不同的方式使用。

请注意，以下提供的列表并不详尽，旨在作为示例，以帮助维护人员在规划和审查更改时提供指导。

ast-spec 和 visitor-keys​

对 AST 的更改应被视为重大更改，如果它

  • 删除或重命名现有的 AST 节点。
  • 删除或重命名 AST 节点上的现有属性。
  • 以非细化方式更改类型（例如，string 到 number）。

对 AST 的更改不应被视为重大更改，如果它

  • 向 AST 添加新属性。
  • 向 AST 添加新的节点类型。
  • 向现有联合类型添加新的节点类型。
  • 细化类型以使其更具体（例如，string 到 'literal' | 'union'）。
  • 从错误添加且与运行时 AST 不匹配的联合中删除类型。

eslint-plugin​

对插件的更改应被视为重大更改，如果它将要求用户更改其配置。更具体地说

  • 删除或重命名选项。
  • 更改规则的默认选项。
  • 更改规则的模式以使其更严格。
  • 将类型信息消耗到以前未消耗它的规则。
  • 删除或重命名规则。
  • 更改任何推荐的配置。
  • 以某种方式更改规则的默认行为，从而在平均代码库中大量情况下导致新的报告。

对插件的更改不应被视为重大更改，如果它

  • 添加默认情况下不会删除现有功能的选项。
  • 添加一条规则。
  • 弃用一条规则。
  • 为现有规则添加额外的检查，这会在中等规模的代码库中导致少量到中等数量的新报告。
  • 重构规则的代码，不会引入额外的报告。
  • 更改规则的描述或其他元数据。
  • 添加修复程序或建议修复程序。
  • 删除修复程序或建议修复程序。
  • 修复规则中的错误行为，这可能会或可能不会引入额外的报告。

parser, typescript-estree, scope-manager, types, type-utils, utils​

对这些包的更改将被视为破坏性更改，如果它

  • 以向后不兼容的方式更改 API 表面（删除或重命名函数、类型等）。

对这些包的更改将不会被视为破坏性更改，如果它

  • 添加到 API 表面（添加函数、类型等）。
  • 弃用 API 表面的部分内容。
  • 向函数或属性添加可选参数到输入类型。
  • 向输出类型添加额外的属性。
  • 以 JSDoc 注释的形式添加文档。

内部包​

此项目中不属于我们公共 API 表面的任何包（例如 eslint-plugin-internal 或 website）在计算新包版本时将不被考虑。