メインコンテンツへスキップ

バージョニング

私たちはセマンティックバージョニング（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など）は、新しいパッケージバージョンを計算する際に考慮されません。