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

OpenTofu v1.x 互換性の保証

OpenTofu v1.6 のリリースは、OpenTofu 言語とワークフローの開発における重要なマイルストーンとなります。OpenTofu v1.x は、インフラストラクチャの記述と管理のための安定したプラットフォームです。

今回のリリースでは、1.x リリース全体を通して互換性を維持する予定の OpenTofu の動作をいくつか定義しています。

  • OpenTofu 言語機能の大部分。
  • OpenTofu CLI ワークフロー コマンドのより保守的なサブセット。
  • OpenTofu Core と OpenTofu プロバイダー間の通信のワイヤプロトコル。
  • プロバイダーと外部モジュールのインストールのためのワイヤプロトコル。

OpenTofu v1.6 用に作成されたモジュールは、v1.x リリース全体で変更を必要とせずに、正常にプランと適用を継続できることを意図しています。

また、このドキュメントで説明されているワークフロー サブセットに基づいて構築された自動化は、今後のすべての v1.x リリースで変更なしに動作することを意図しています。

最後に、現在ドキュメント化されているプロバイダー ワイヤ プロトコルに対して構築されたプロバイダーは、ソース コードの変更やバイナリの再コンパイルを必要とせずに、同じオペレーティング システムとアーキテクチャをターゲットとする今後のすべての OpenTofu v1.x リリースと互換性があることを意図しています。

要するに、v1.x リリース間のアップグレードを簡単にするよう努めています。設定の変更、アップグレード手順を実行するための追加のコマンド、OpenTofu の周りに設定した自動化の変更は必要ありません。

OpenTofu v1.x シリーズは、v1.6 以降少なくとも 18 か月間、積極的にメンテナンスされます。

次のセクションでは、詳細を知りたい方のために、v1.x シリーズ全体で約束することに関する具体的なガイダンスをいくつか紹介します。ただし、より高いレベルでは、新しい v1.x リリースにアップグレードする際に、既存のモジュールや自動化が変更を必要とするような変更を行う予定はありません。新しい OpenTofu CLI リリースの互換性の問題は、重大なセキュリティ問題に対処したり、当社が直接制御できないリモート依存関係への破壊的変更に対応したりするなど、変更の正当な理由が非常に大きい場合を除き、修正されるバグとして扱います。

OpenTofu 言語​

メインの OpenTofu 言語には、言語構文、resource、module、provider ブロックなどの最上位構造、それらのブロック内の「メタ引数」、および式で使用できる演算子と組み込み関数のドキュメント化されたセマンティクスと動作が含まれます。

OpenTofu 言語の単一の正式な仕様はありませんが、OpenTofu Web サイトのドキュメントの「構成」セクションが、言語機能とその意図された動作の説明として機能します。

次の最上位ブロックと、定義された「メタ引数」(つまり、プロバイダーなどの外部プラグインではなく OpenTofu Core によって定義された引数) は、現在の機能を維持します。

  • resource および data ブロック (リソースを宣言するため) (ネストされたブロック タイプ lifecycle、connection、および provisioner、およびメタ引数 provider を含む)。
  • module ブロック (他のモジュールを呼び出すため) と、そのメタ引数 providers。
  • resource、data、および module ブロックのcount、for_each、および depends_on メタ引数。
  • プロバイダーを構成するためのprovider ブロックと、alias メタ引数。
  • モジュール内のさまざまな種類の名前付き値を宣言するためのvariable、output、およびlocals ブロック。
  • ネストされたrequired_version および required_providers 引数、バックエンド構成用のネストされたbackend ブロックを含む、terraform ブロック。

また、式演算子と組み込み関数については、terraform.workspaceへの参照を除き、すべて互換性を維持する予定です。terraform.workspaceについては、ワークスペースモデルの将来の変更の一環として、その動作が変更される可能性があります。

OpenTofuの言語機能との広範な互換性を維持する予定ですが、いくつかの注意点があります。

  • OpenTofuがエラーを報告することなく、構成のプランを作成および適用できる場合、その構成は有効であるとみなします。

    現在エラーが発生する構成は、将来のバージョンのOpenTofuでは異なるエラーを生成したり、エラー以外の動作を示す可能性があります。適用フェーズ中にエラーが発生する構成は、将来、より早い段階で同様のエラーを生成する可能性があります。これは、一般的にエラーをできるだけ早い段階で検出することが望ましいと考えているためです。

    一般的に、このドキュメントで説明されている互換性の保証は、有効な構成にのみ適用されます。無効な構成の取り扱いは、将来のOpenTofuリリースで常に変更される可能性があります。

  • 機能の実際の動作が、その機能の動作として明示的に文書化された内容と異なる場合、通常はそれをバグとして扱い、ドキュメントに合わせて機能を変更しますが、広範な互換性の問題を引き起こす可能性が高いと思われる場合は、そのような変更を避けます。以前のリリースとの「バグ互換性」を常に維持することは約束できませんが、その影響を最小限に抑えるために、そのような修正を慎重に検討します。

  • 実験的な機能は、将来のリリースで変更または完全に削除される可能性があります。OpenTofuは、実験的な言語機能が有効になっている場合は常に警告を発行し、そのリスクを認識できるようにします。本番環境のモジュールで実験的な機能を使用することはお勧めしません。

  • 新しい言語機能を導入する予定であり、それらの使用を開始すると、その機能をまだサポートしていない以前のOpenTofuバージョンでは構成が動作しなくなります。

  • プロバイダーはOpenTofu Coreとは独立して変更できる個別のプラグインであるため、これらの互換性の保証の対象ではありません。使用しているプロバイダーのいずれかをアップグレードする場合は、それらのプロバイダーに関連するプロバイダーまたはリソースの構成を変更する必要がある場合があります。

  • OpenTofu v1.6では、少数の機能が明示的な警告とともに非推奨のまま残されています。これらの非推奨サイクルは将来のv1.xリリースで終了し、その時点で対応する機能は削除されます。

ワークフロー​

OpenTofuでよく使用される一連のワークフローがあり、これを保護されたワークフローと呼んでいます。これらのコマンド、サブコマンド、およびフラグを削除したり、保護されたワークフローの機能に後方互換性のない変更を加えることはありません。誤ってこれらを変更した場合は、コアワークフローへの後方互換性のない変更は修正されるべきバグとみなします。保護されたワークフローの一部であるコマンドとオプションの組み合わせのリストについては、保護されたワークフローコマンドを参照してください。v1.xリリースで機能が変更される可能性があるため、互換性の保証を明示的に行わないコマンドのセットが別にあります。 変更される可能性のあるコマンドを参照してください。

外部ソフトウェアがOpenTofuと対話するためのサポートされている方法は、一部のコマンドで提供されるJSON出力モードと終了ステータスコードによるものです。特定のJSON形式に新しいオブジェクトプロパティを追加する場合がありますが、既存のプロパティの定義を削除したり、破壊的な変更を加えたりすることはありません。

自然言語のコマンド出力またはログ出力は安定したインターフェースではなく、新しいバージョンで変更される可能性があります。この出力を解析するソフトウェアを作成する場合は、OpenTofuをアップグレードするときに更新が必要になる場合があります。機械可読なJSONインターフェースのいずれかで現在利用できないデータへのアクセスが必要な場合は、ユースケースについて話し合うための機能リクエストを開くことをお勧めします。

アップグレードとダウングレード​

v1.xシリーズのリリース全体で、特別なアップグレード手順なしで、新しいOpenTofuバージョンに切り替えて以前と同じように使用できるようにする予定です。

任意のv1.xリリースからそれ以降の任意のv1.xリリースにアップグレードできる必要があります。以前のv1.xリリースにダウングレードすることもできる可能性がありますが、保証はされていません。後のリリースでは、OpenTofu状態スナップショットの新しいストレージ形式など、以前のバージョンが理解できない新しい機能が導入される可能性があるためです。

後のv1.xリリースで導入された機能を使用する場合、その機能よりも前のリリースとの互換性はなくなります。たとえば、v1.7で言語機能が追加され、それを使用し始めると、OpenTofu構成はOpenTofu v1.6と互換性がなくなります。

プロバイダー​

OpenTofuプロバイダーは、文書化されたプロトコルを使用してOpenTofuと通信する個別のプラグインです。したがって、これらの互換性の保証は、OpenTofu Coreによって実装されたこのプロトコルの「クライアント」側のみを対象とすることができます。サポートするリソースタイプや期待される引数など、個々のプロバイダーの動作は、プロバイダー開発チームによって決定され、OpenTofu Coreのリリースとは独立して変更される可能性があります。

プロバイダーの新しいバージョンにアップグレードする場合は、OpenTofu v1.xリリースを使用している場合でも、そのプロバイダーによって解釈される構成の部分を変更する必要がある場合があります。

プロバイダーのインストール方法​

OpenTofuは通常、プロバイダーレジストリプロトコルのバージョン1を実装するプロバイダーレジストリからプロバイダーをインストールします。すべてのOpenTofu v1.xリリースは、そのプロトコルとの互換性を維持するため、正しく実装されたプロバイダーレジストリは互換性を維持します。

OpenTofuは、ローカルファイルシステムディレクトリ（ファイルシステムミラー）およびネットワークミラー（プロバイダーミラープロトコルを実装）からのプロバイダーのインストールもサポートしています。すべてのOpenTofu v1.xリリースは、暗黙のローカルミラーディレクトリを含む、これらのインストール方法との互換性を維持します。

特定のプロバイダーレジストリまたはネットワークミラーは、OpenTofu自体とは独立して実行されるため、それらの独自の動作はこれらの互換性の保証の対象ではありません。

プロバイダープロトコルバージョン​

OpenTofu v1.6の時点でのプロバイダープラグインプロトコルの現在のメジャーバージョンはバージョン5です。これは、物理的なワイヤ形式を記述するProtocol Buffersスキーマと、期待されるプロバイダーの動作を記述する追加の散文ドキュメントの組み合わせによって定義されています。

OpenTofu v1.xリリース全体でプロトコルバージョン5をサポートします。後のリリースでプロトコルバージョン5に新しいマイナーリビジョンを加える場合は、既存のプラグインがプロトコルを正しく実装していれば引き続き動作するように設計します。

v1.xシリーズ中にプロトコルの新しいメジャーバージョンを導入する可能性があります。その場合は、これらの新しいバージョンと並行してプロトコルバージョン5のサポートを継続します。個々のプロバイダーチームは、後のリリースでプロトコルバージョン5のサポートを削除することを決定する可能性があり、その場合、これらの新しいプロバイダーリリースは、すべてのOpenTofu v1.xリリースと互換性がなくなります。

外部モジュール​

モジュールは、OpenTofu言語で記述された再利用可能なインフラストラクチャコンポーネントです。一部のモジュールは、OpenTofuが現在の構成ディレクトリ以外の場所から自動的にインストールするという意味で「外部」です。この場合、その内容は、ローカルモジュール、使用するプロバイダー、およびOpenTofu自体の変更とは独立して変更される可能性があります。

モジュールのインストール方法​

OpenTofuは、さまざまなモジュールソースタイプから子モジュールをインストールすることをサポートしています。v1.xリリース全体で、既存のすべてのソースタイプを引き続きサポートします。

サポートされているソースタイプの1つは、モジュールレジストリプロトコルバージョン1を実装するモジュールレジストリです。すべてのOpenTofu v1.xリリースは、そのプロトコルの正しい実装との互換性を維持します。

一部のモジュールソースタイプは、サードパーティによって定義および実行されるサービスまたはプロトコルと直接連携します。OpenTofu自身のクライアント側のサポートを削除することはありませんが、それらの所有者がこれらのサービスの実行を維持することや、OpenTofuのクライアント実装との互換性を維持することを保証することはできません。

外部モジュールの互換性​

構成が外部モジュールに依存している場合、これらのモジュールの新しいバージョンには破壊的な変更が含まれる可能性があります。外部モジュールはOpenTofuの一部ではないため、これらの互換性の保証の対象ではありません。

プロビジョナー​

すべてのv1.xリリースを通じて、file、local-exec、およびremote-execプロビジョナータイプの互換性を維持します。

OpenTofuは、特定のローカルファイルシステムディレクトリからプラグインとして追加のプロビジョナーをロードすることをサポートしています。OpenTofu v1.xリリース全体でこれを引き続きサポートしますが、このようなプラグインはOpenTofu Core自体とは別であるため、それらの独自の動作はこれらの互換性の保証の対象にはなりません。ただし、OpenTofu v1.6で定義されているプラグインワイヤプロトコルは、v1.xリリース全体で引き続きサポートするため、正しく実装されたプロビジョナープラグインは、将来のOpenTofuリリースとの互換性を維持する必要があります。

状態ストレージバックエンド​

リモート状態を使用する場合、OpenTofuは、OpenTofu状態の保存とロックの管理のために、ネットワークを介してリモートサービスと対話します。

歴史的な理由により、サポートされているすべての状態ストレージバックエンドはOpenTofu CLIの一部として含まれていますが、OpenTofuチームが直接サポートしているわけではありません。OpenTofuチームがメンテナンスしている以下のバックエンドのみが、互換性の保証の対象となります。

  • local（リモート状態を使用していない場合のデフォルト）
  • http

他の状態ストレージバックエンドは、OpenTofu CLIのコードベースへの貢献を通じて外部チームによってメンテナンスされているため、それらの予期される設定引数や動作は、v1.xリリースであっても変更される可能性があります。ただし、可能な限り、そのような場合には適切な移行パスを確保することを目指します。

プロバイダープラグインと同様に、プラグインを介した外部状態ストレージバックエンドの実装を許可することを検討しています。v1.xリリース中にそのようなメカニズムを導入した場合、これらのプラグインを使用するために設定変更が必要になる可能性があり、上記のリストにない状態ストレージバックエンドは、同等のプラグインが利用可能になった後、OpenTofu CLIの後のバージョンから削除される可能性があります。

remoteバックエンド​

remoteバックエンドの動作は途中で変更される可能性があるため、これらの互換性の保証の対象外です。

コミュニティがメンテナンスしている状態ストレージバックエンド​

azurerm、consul、s3、およびkubernetesバックエンドは、HashiCorpの他のチームによってメンテナンスされています。これらのチームは、バックエンド用のプラグインプロトコルを実装しない限り、v1.xリリースを通じてバグ修正レベルでの基本的なメンテナンスを継続する予定です。プラグインプロトコルを実装した場合、これらのバックエンドの開発は外部プラグインでのみ継続される可能性が高く、プラグインの同等物に切り替えるために設定変更が必要になる場合があります。

cos、oss、pg、gcs、およびetcdv3バックエンドは、外部のコントリビューターによってメンテナンスされており、これらの互換性の保証の対象外です。

メンテナンスされていない状態ストレージバックエンド​

artifactory、etcdv2、manta、およびswiftの状態ストレージバックエンドは現在、メンテナーがおらず、OpenTofu CLIリリースに最善の努力に基づいて残されています。これらは後のv1.xリリースで削除される可能性があり、統合するサービスに対する破壊的な変更が発生した場合、更新されません。

サポートされているプラットフォーム​

v1.xシリーズを通じて、以下のプラットフォームの公式リリースを継続し、これらのオペレーティングシステムの新しいリリースをサポートするために必要な変更を行います。

  • x64 CPU上のmacOS（darwin_amd64）
  • x64 CPU上のWindows（windows_amd64）
  • x64、32ビットARMv6、および64ビットARMv8上のLinux（それぞれlinux_amd64、linux_arm、およびlinux_arm64）

時間の経過とともに、これらのオペレーティングシステムの新しいバージョンが必要になる場合があります。たとえば、v1.xシリーズの後のOpenTofuリリースでは、以前のバージョンのmacOSまたはWindows、または以前のLinuxカーネルリリースのサポートが終了する可能性があります。

これまで、これらのプラットフォームのユーザーの便宜のために、他の多くのプラットフォームの公式リリースを作成してきましたが、それらを公開するのをやめる現在の計画はありませんが、v1.xシリーズを通じて他のプラットフォームの継続的なリリースやバグ修正を約束することはできません。上記のリストにないプラットフォームでOpenTofuを日常的にテストすることはありません。

後のv1.xリリースで新しいプラットフォームのサポートを追加する可能性があります。その場合、そのサポートより前の以前のOpenTofuリリースは、これらのプラットフォームでは利用できません。

プロバイダープラグインを含むすべてのOpenTofuプラグインは、サポートするプラットフォームに関する独自のポリシーを持つ個別のプログラムです。OpenTofu CLI自体がそれらをサポートする場合でも、すべてのプロバイダーが現在上記のリストにあるプラットフォームをサポートしているか、今後もサポートし続けることを保証することはできません。

これらの保証の後の改訂​

新しい機能に関連する保証を記述するため、または以前のステートメントが不明確であったというフィードバックがあった場合に既存の保証を明確にするために、v1.xシリーズを通じてこれらの保証を拡張または改良する場合があります。

新しい機能に関する保証は、既存の保証を取り消すことなく、さらに保証を追加するという意味で付加的になります。後のv1.xリリースのみに適用される保証については、それらの保証が適用される最初のバージョンを記載します。

このドキュメントに明示的なステートメントを追加しなくても、特に明記されていない限り、後のv1.xリリースで追加された非実験的な機能は、少なくともv1.xシリーズの残りの期間は互換性を維持することを意図しています。

付録​

保護されたワークフローコマンド​

以下は、これらの互換性の保証の対象となるOpenTofu CLIサブコマンドおよびオプションのリストです。これらのコマンドを中心に自動化を構築する場合は、後のすべてのv1.xリリースと互換性があるはずです。

上記のように、外部ソフトウェアとの互換性は、明示的に機械可読な出力（-jsonおよび-rawモード）と終了コードに限定されます。これらのコマンドからの自然言語出力は、後のリリースで変更される可能性があります。

  • init
    • -backend=false
    • -backend-config=FILE
    • -backend-config="KEY=VALUE"
    • -force-copy
    • -get=false
    • -input=false
    • -migrate-state
    • -no-color
    • -plugin-dir=DIR
    • -reconfigure
    • -upgrade
  • validate
    • -json
    • -no-color
  • plan
    • -compact-warnings
    • -destroy
    • -detailed-exitcode
    • -lock=false
    • -lock-timeout=DURATION
    • -input=false
    • -json
    • -no-color
    • -out=FILE
    • -parallelism=N
    • -refresh=false
    • -refresh-only
    • -replace=ADDRESS
    • -target=ADDRESS
    • -var 'NAME=VALUE'
    • -var-file=FILE
  • apply
    • -auto-approve
    • -compact-warnings
    • -lock=false
    • -lock-timeout=DURATION
    • -input=false
    • -json
    • -no-color
    • -parallelism=N
    • -refresh=false
    • -refresh-only
    • -replace=ADDRESS
    • -target=ADDRESS
    • -var 'NAME=VALUE'
    • -var-file=FILE
  • show
    • -no-color
    • -json
    • （プランファイルがある場合とない場合の両方）
  • providers（サブコマンドなし）
  • providers lock
    • -fs-mirror=PATH
    • -net-mirror=URL
    • -platform=OS_ARCH
  • providers mirror
    • -platform=OS_ARCH
  • providers schema
    • -json
  • fmt
    • -list=false
    • -write=false
    • -diff
    • -recursive
    • -check
  • version
    • -json
  • output
    • -no-color
    • -json
    • -raw
  • taint
    • -allow-missing
    • -lock=false
    • -lock-timeout=DURATION
    • -ignore-remote-version
  • untaint
    • -allow-missing
    • -lock=false
    • -lock-timeout=DURATION
    • -ignore-remote-version
  • force-unlock
    • -force
  • state list
    • -id=ID
  • state pull
  • state push
    • -force
    • -lock=false
    • -lock-timeout=DURATION
  • state show
    • -ignore-remote-version
  • login

上記のリストにないコマンドまたはオプションについては、可能な限り破壊的な変更を避けますが、v1.xシリーズ全体での完全な互換性を保証することはできません。OpenTofuを中心に自動化を構築する場合は、アップグレード時に変更する必要性を避けるために、上記のコマンドのみを使用してください。

OpenTofuの内部ログ（TF_LOG環境変数を介して）はJSON形式で利用できますが、それらのログ行の特定の構文または構造は、サポートされている統合インターフェースではありません。ログは、OpenTofu開発者によるログの臨時のフィルタリングと処理を支援するためだけにJSONとして利用できます。

変更される可能性のあるコマンド​

以下のすべてのコマンドとそのサブコマンド/オプションは、v1.xシリーズ中に改善する既存の計画があるか、継続的なメンテナンスのために破壊的な変更が必要になる可能性のある設計上の欠点があるため、互換性の保証の対象外です。

サポートされている限り、OpenTofuをインタラクティブに実行するときにこれらのコマンドを自由に使用できますが、後のv1.xリリースにアップグレードするときにその自動化を更新する可能性がある場合を除き、自動化の一部として使用することはお勧めしません。

  • destroy（代わりにtofu apply -destroyを検討してください）
  • console
  • get（代わりにtofu initを検討してください）
  • graph
  • import
  • push
  • refresh（代わりにtofu apply -refresh-onlyを検討してください）
  • state mv
  • state replace-provider
  • state rm
  • workspace（および非推奨のエイリアスenv）のすべてのサブコマンド

今後のリリースでこれらのコマンドに関連付けられた主なユースケースのサポートを維持する予定ですが、それらのユースケースを満たすために使用される正確なコマンド名やオプションを維持することは保証できません。

これらの保証をどのように守るか​

自動回帰テスト​

OpenTofuのコードベースには、安定版で出荷される前に、意図しない動作の回帰に気づくのに役立つように設計されたさまざまなユニットテストと統合テストが含まれています。

ただし、OpenTofuは、興味深い方法で相互作用する可能性のある多くの異なる機能を備えた比較的複雑なシステムです。過去に、以前に予期していなかった方法で2つ以上の機能を組み合わせた場合にのみ表示される動作の違いに関するレポートがありました。または自動テストを作成しました。

それぞれの場合において、互換性の問題を解決するための変更を実装し、その機能の組み合わせの動作を表す1つ以上の統合テストを追加しました。OpenTofuのテストカバレッジを時間の経過とともに向上させることができるように、このアプローチを継続する予定です。

プレリリースバージョン​

これらの保証の対象となるほとんどの意図しない動作の変更は、既存のテストによって検出されることを意図しています。ただし、テストスイートがすべての可能な機能の相互作用やその他のエッジケースを完全にカバーできるわけではないことも受け入れているため、最終リリースに含まれる前に、各重要な変更がアルファリリースとベータリリースの両方に含まれることを目指しています。

マイナーリリースについては、通常、最終リリースの前に少なくとも1つのリリース候補も発行します。リリース候補は、計画された開発が完了し、アルファおよびベータリリースに基づいて報告された回帰を修正したことを示します。したがって、それに続く最終リリースは、通常、最新のリリース候補と完全に一致するか、ほぼ一致する必要があります。

最終リリースでの回帰​

機能のより曖昧な組み合わせの場合、プレリリース期間中に回帰が検出されず、最終リリースに含まれる可能性があります。

リリース後すぐにそのような回帰を見つけて報告した場合は、バグとして扱い、セキュリティアドバイザリなどの非常に重要な正当な理由がない限り、将来のリリースで以前の動作を復元するように修正します。このような場合、通常、回帰の影響を受けるすべての人に、問題が修正されるまで以前のバージョンを使用し続け、その修正を含む新しいリリースに直接スキップすることをお勧めします。

アルファ、ベータ、およびリリース候補パッケージに対してモジュールを事前にテストすることにより、最終リリースでの見過ごされた回帰の影響を受けるリスクを最小限に抑えることができます。本番インフラストラクチャではなく、隔離された開発環境またはステージング環境でのみこれを行うことをお勧めします。このドキュメントの保証に反するように見えるプレリリースビルドでの動作の変化を見つけた場合は、OpenTofuのGitHubリポジトリで問題を提起して議論してください。

遅れて報告された回帰​

最も極端なケースでは、機能の組み合わせによるリグレッションがあまりにもまれであるため、長期間検出されない可能性があります。

変更がより多くのリリースに含まれると、他のユーザーが新しい動作に依存する可能性が高くなり、そのため、動作を復元することが新しい動作を維持するよりも大きな悪影響を及ぼすかどうかを判断するためのトレードオフが必要になります。私たちは常に、それぞれの固有の状況の影響を十分に考慮してこの決定を行います。

OpenTofuのマイナーリリースおよびパッチリリースに迅速にアップグレードし、OpenTofuのGitHubリポジトリで発生した互換性の問題を報告することで、モジュールが遅れて報告されたリグレッションの影響を受けるリスクを最小限に抑えることができます。

現実的な例外​

OpenTofuモジュールや自動化への投資が、OpenTofuの将来の変更によって無効にならないように、上記を誠意をもって約束します。ただし、上記のような広範な約束は、OpenTofuの開発を続ける中で発生する可能性のある実際的な問題のすべてのニュアンスを網羅することはできません。

そのため、既存のモジュールや自動化に影響を与える可能性のある変更を依然として行う必要のある状況がいくつかあります。

  • セキュリティ上の問題: 重大なセキュリティ上の影響を与える設計上の問題に気づく場合があります。関連するリスクの判断に応じて、より安全なシステムを実現するために互換性を破ることを選択する場合があります。
  • 外部依存関係: OpenTofuの動作は、選択したオペレーティングシステムや、モジュールやプロバイダーのインストールなどの状況で使用される一部のリモートネットワークサービスなど、外部コードベースによって提供されるインターフェースに依存しています。これらの外部システムは、OpenTofu自身の機能が依存している機能の削除や変更を含め、私たちの制御外で変更される可能性があります。その場合、適切な代替メカニズムがない場合は、新しい制約内で動作するようにOpenTofuの設計を変更する必要があるかもしれません。
  • オプトインによる互換性の破壊: 新しい言語機能の設計では、既存の機能の動作や構成表現の変更が必要になる場合があります。その場合、既存のモジュールが壊れないように、通常は新しい機能をオプトインのみにします。ただし、新しい機能にオプトインするようにモジュールを変更すると、新しい言語設計で動作するように構成の他の部分も変更する必要がある場合があります。
  • 新機能のバグ: OpenTofuに新しい機能を導入し、初期実装に問題があり、リリース時のドキュメントに記載された設計意図と一致しない場合、ドキュメントに記載された設計と一致するように実装を修正するフォローアップリリースを行う場合があります。たとえそれが初期実装と比較してわずかな互換性リグレッションを表すとしてもです。ただし、機能が十分に確立され、一般的に使用されるようになったら、通常は実装された動作を優先し、代わりにそれを反映するようにドキュメントを変更します。
  • 既存の機能のリグレッション: 開発およびプレリリース期間中に検出されなかった既存の機能のリグレッションが新しいOpenTofuリリースに含まれていることが判明し、その事実が新しいリリースの直後に判明した場合は、通常、より多くのユーザーがリグレッションの影響を受けるシステムを抱えていると想定して、新しいリリースで導入された動作に依存しているシステムよりも、技術的に新しいリリースの動作との互換性を破って以前の動作を復元します。
  • 遅れて報告されたリグレッション: 前のセクションで説明したように、はるかに以前のリリースで、まれに使用される機能または機能の組み合わせの意図しないリグレッションがあったことが判明した場合、以前の動作を復元すると、後から採用したユーザーにはリグレッションとして認識される可能性があります。リグレッションを修正することで、リグレッション自体が影響を与えるよりも多くのユーザーに影響を与える可能性があると判断した場合、リグレッションを新しい約束された動作として受け入れることを選択する場合があります。
  • 予期できない状況: ここではさまざまな特定の例外的な状況を検討するよう努めてきましたが、OpenTofuとその開発プロセスはより広範なコンテキストから隔離されているわけではないため、OpenTofuの将来に影響を与える可能性のある、予期できない状況が発生する可能性があることを考慮する必要があります。そのような状況では、既存のモジュールと自動化への影響を可能な限り最小限に抑える行動方針を常に最善を尽くして見つけます。

これらの現実的な例外の意図は、一般的な互換性の約束では対処できない状況が常に存在することを認識することのみです。これらの例外は、十分に検討した上で、最後の手段としてのみ使用します。