Обещания совместимости OpenTofu v1.x

Выпуск OpenTofu v1.6 стал важной вехой в развитии языка и рабочего процесса OpenTofu. OpenTofu v1.x — это стабильная платформа для описания инфраструктуры и управления ею.

В этом выпуске мы определяем ряд особенностей поведения OpenTofu, совместимость с которыми мы намерены сохранять на протяжении всех выпусков 1.x:

• Большое подмножество возможностей языка OpenTofu.
• Более ограниченное подмножество команд рабочего процесса OpenTofu CLI.
• Протокол обмена данными между OpenTofu Core и провайдерами OpenTofu.
• Протоколы обмена данными для установки провайдеров и внешних модулей.

Мы намерены обеспечить, чтобы модули, написанные для OpenTofu v1.6, продолжали успешно выполнять планирование и применение без необходимости изменений во всех выпусках v1.x.

Мы также намерены обеспечить работу средств автоматизации, построенных на основе подмножества рабочего процесса, описанного в этом документе, без изменений во всех будущих выпусках v1.x.

Наконец, мы намерены обеспечить совместимость провайдеров, созданных с использованием описанного в настоящее время протокола обмена данными с провайдерами, со всеми будущими выпусками OpenTofu v1.x для той же операционной системы и архитектуры без необходимости изменения исходного кода или повторной компиляции двоичных файлов.

Короче говоря, мы стремимся сделать переход между выпусками v1.x простым: не требующим изменений конфигурации, дополнительных команд для обновления или изменений в настроенных вами средствах автоматизации OpenTofu.

Серия OpenTofu v1.x будет активно поддерживаться как минимум в течение 18 месяцев после выпуска v1.6.

В следующих разделах приведены конкретные рекомендации о том, что мы обещаем на протяжении серии v1.x, для тех, кому нужны подробности. Однако в целом мы не намерены вносить изменения, из-за которых существующие модули или средства автоматизации потребуется менять при переходе на новый выпуск v1.x. Обычно проблемы совместимости в новых выпусках OpenTofu CLI мы будем считать ошибками, которые нужно исправить, если только для изменения не будет очень веских причин, например необходимости устранить критическую проблему безопасности или соответствовать несовместимому изменению удалённой зависимости, на которую мы не можем напрямую повлиять.

Язык OpenTofu​

Основной язык OpenTofu включает синтаксис языка, структуры верхнего уровня, такие как блоки resource, module и provider, «метааргументы» в этих блоках, а также документированные семантику и поведение операторов и встроенных функций, доступных для использования в выражениях.

Для языка OpenTofu не существует единой формальной спецификации, однако раздел Configuration документации на сайте OpenTofu служит описанием возможностей языка и предполагаемого поведения этих возможностей.

Следующие блоки верхнего уровня и определённые для них «метааргументы» (то есть аргументы, определяемые OpenTofu Core, а не внешними плагинами, например провайдерами) сохранят свою текущую функциональность:

• resource и data для объявления ресурсов, включая их вложенные типы блоков lifecycle, connection и provisioner, а также метааргумент provider.
• module для вызова других модулей и метааргумент providers.
• Метааргументы count, for_each и depends_on в блоках resource, data и module.
• provider для настройки провайдеров и метааргумент alias.
• Блоки variable, output и locals для объявления различных видов именованных значений в модуле.
• Блоки terraform, включая вложенные аргументы required_version и required_providers, а также вложенные блоки backend для настройки бэкенда.

Мы также намерены сохранить совместимость со всеми операторами выражений и встроенными функциями, за исключением ссылок на 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, описывающей физические форматы обмена данными, и дополнительной текстовой документации, описывающей ожидаемое поведение провайдеров.

Мы будем поддерживать протокол версии 5 на протяжении всех выпусков OpenTofu v1.x. Если в более поздних выпусках мы создадим новые минорные редакции протокола версии 5, мы разработаем их так, чтобы существующие плагины продолжали работать при условии корректной реализации протокола.

В серии v1.x мы можем представить новые основные версии протокола. В таком случае мы продолжим поддерживать протокол версии 5 наряду с новыми версиями. Отдельные команды разработчиков провайдеров могут решить отказаться от поддержки протокола версии 5 в более поздних выпусках, и тогда эти новые выпуски провайдеров будут несовместимы с некоторыми выпусками OpenTofu v1.x.

Внешние модули​

Модули — это повторно используемые компоненты инфраструктуры, написанные на языке OpenTofu. Некоторые модули являются «внешними»: OpenTofu автоматически устанавливает их из местоположения, отличного от каталога текущей конфигурации. В этом случае их содержимое может меняться независимо от локальных модулей, используемых вами провайдеров и самой OpenTofu.

Способы установки модулей​

OpenTofu поддерживает установку дочерних модулей из нескольких типов источников модулей. Мы продолжим поддерживать все существующие типы источников на протяжении всех выпусков v1.x.

Один из поддерживаемых типов источников — реестр модулей, реализующий протокол реестра модулей версии 1. Все выпуски OpenTofu v1.x сохранят совместимость с корректными реализациями этого протокола.

Некоторые типы источников модулей напрямую взаимодействуют со службами или протоколами, определяемыми и обслуживаемыми третьими сторонами. Мы не будем удалять собственную клиентскую поддержку OpenTofu для таких источников, однако не можем гарантировать, что их владельцы продолжат поддерживать эти службы или что они сохранят совместимость с клиентскими реализациями OpenTofu.

Совместимость внешних модулей​

Если ваша конфигурация зависит от внешних модулей, новые версии этих модулей могут содержать несовместимые изменения. Внешние модули не входят в состав OpenTofu и поэтому не подпадают под эти обещания совместимости.

Средства подготовки​

Мы будем поддерживать совместимость типов средств подготовки file, local-exec и remote-exec во всех выпусках v1.x.

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 мы продолжим выпускать официальные версии для следующих платформ и при необходимости вносить изменения для поддержки новых выпусков этих операционных систем:

• macOS на процессорах x64 (darwin_amd64)
• Windows на процессорах x64 (windows_amd64)
• Linux на x64, 32-разрядных ARMv6 и 64-разрядных ARMv8 (соответственно linux_amd64, linux_arm и linux_arm64)

Со временем для работы OpenTofu могут потребоваться более новые версии этих операционных систем. Например, в последующих выпусках OpenTofu серии v1.x может быть прекращена поддержка более ранних версий 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, конкретный синтаксис или структура строк журнала не являются поддерживаемым интерфейсом интеграции. Журналы доступны в формате JSON лишь для удобства выборочной фильтрации и обработки разработчиками OpenTofu.

Команды, которые могут измениться​

На все перечисленные ниже команды и их подкоманды и параметры не распространяются обещания совместимости: либо у нас уже есть планы улучшить их в серии 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 — относительно сложная система со множеством функций, которые могут интересным образом взаимодействовать друг с другом. В прошлом мы получали сообщения о различиях в поведении, которые проявлялись только при сочетании двух или более функций способом, который мы ранее не предвидели и для которого не написали автоматизированные тесты.

В каждом таком случае мы не только вносили изменения для решения проблемы совместимости, но и добавляли один или несколько интеграционных тестов, описывающих такое сочетание функций. Мы намерены и дальше придерживаться этого подхода, чтобы со временем улучшать покрытие OpenTofu тестами.

Предварительные версии​

Мы рассчитываем, что большинство случайных изменений поведения, подпадающих под эти обещания, будут обнаружены существующими тестами. Однако мы также признаём, что наш набор тестов никогда не сможет охватить все возможные взаимодействия функций и другие крайние случаи. Поэтому мы стремимся включать каждое существенное изменение сначала в альфа- и бета-версии, а затем — в окончательный выпуск.

Для выпусков с незначительными изменениями мы обычно также выпускаем как минимум одну версию-кандидат до окончательного выпуска. Версия-кандидат означает, что запланированная разработка завершена и мы исправили регрессии, о которых сообщили пользователи альфа- и бета-версий. Поэтому последующий окончательный выпуск обычно должен точно или почти точно соответствовать последней версии-кандидату.

Регрессии в окончательных выпусках​

При более редких сочетаниях функций регрессия может остаться незамеченной на этапах предварительных выпусков и поэтому попасть в окончательный выпуск.

Если кто-то обнаружит и сообщит о такой регрессии вскоре после выпуска, мы будем рассматривать её как ошибку и исправим её в будущих выпусках, чтобы восстановить прежнее поведение, если только для этого нет веских оснований, например рекомендаций по безопасности. В таких случаях мы обычно рекомендуем всем, кого затронула регрессия, использовать предыдущую версию до устранения проблемы, а затем сразу перейти на новый выпуск с исправлением.

Вы можете снизить риск последствий регрессий, пропущенных в окончательных выпусках, заблаговременно тестируя модули с альфа-, бета-версиями и версиями-кандидатами. Рекомендуем делать это только в изолированных средах разработки или тестирования, а не в рабочей инфраструктуре. Если вы обнаружите в предварительной сборке изменение поведения, которое, по вашему мнению, противоречит обещаниям в этом документе, сообщите об этом, создав задачу в репозитории OpenTofu на GitHub.

Регрессии, обнаруженные с опозданием​

В самом крайнем случае регрессия, связанная с сочетанием функций, может быть настолько редкой, что долгое время останется незамеченной.

Чем больше выпусков включает изменение, тем выше вероятность, что другие пользователи начнут полагаться на новое поведение. Поэтому нам придётся искать компромисс и решать, не окажет ли восстановление прежнего поведения более негативное влияние, чем сохранение нового. Принимая такое решение, мы всегда будем тщательно учитывать последствия каждой конкретной ситуации.

Вы можете снизить риск того, что ваши модули затронут регрессии, обнаруженные с опозданием, своевременно обновляя OpenTofu до новых выпусков с незначительными изменениями и исправлениями и сообщая о любых проблемах совместимости, с которыми столкнётесь, в репозитории OpenTofu на GitHub.

Практические исключения​

Мы даём приведённые выше обещания добросовестно и стремимся к тому, чтобы ваши вложения в разработку модулей или средств автоматизации для OpenTofu не обесценились из-за будущих изменений OpenTofu. Однако столь общие обещания не могут учесть все нюансы практических проблем, которые могут возникнуть в ходе дальнейшей разработки OpenTofu.

Поэтому в некоторых ситуациях нам всё же может потребоваться внести изменения, которые повлияют на существующие модули или средства автоматизации:

• Проблемы безопасности: Мы можем обнаружить проблему проектирования, которая существенно влияет на безопасность. В зависимости от оценки связанного с ней риска мы можем решить нарушить совместимость, чтобы сделать систему безопаснее.
• Внешние зависимости: Поведение OpenTofu зависит от интерфейсов, предоставляемых сторонними кодовыми базами, в том числе выбранной вами операционной системой и некоторыми удалёнными сетевыми службами, используемыми, например, для установки модулей и провайдеров. Эти внешние системы могут меняться вне нашего контроля, в том числе удалять или изменять функции, от которых зависят возможности самого OpenTofu. Если в таком случае не будет подходящей замены, нам может потребоваться изменить устройство OpenTofu, чтобы оно соответствовало новым ограничениям.
• Изменения совместимости, включаемые по выбору: Для реализации новой языковой функции может потребоваться изменить поведение существующей функции или способ её представления в конфигурации. В таком случае мы обычно делаем новую функцию необязательной, чтобы не нарушать работу существующих модулей. Однако если вы измените модуль, чтобы включить новую функцию, вам также может потребоваться изменить другие части конфигурации в соответствии с новым устройством языка.
• Ошибки в новых функциях: Если мы добавим в OpenTofu новую функцию, а в первоначальной реализации обнаружатся проблемы, из-за которых она не будет соответствовать задокументированному замыслу на момент выпуска, мы можем выпустить обновление, исправляющее реализацию в соответствии с документацией, даже если это приведёт к незначительному нарушению совместимости по сравнению с первоначальной реализацией. Однако после того, как функция будет хорошо зарекомендована и широко распространена, мы обычно будем исходить из реализованного поведения и вместо этого изменим документацию, чтобы она ему соответствовала.
• Регрессии в существующих функциях: Если мы узнаем, что в новом выпуске OpenTofu есть регрессия существующей функции, которую не обнаружили во время разработки и подготовки предварительных выпусков, и узнаем об этом вскоре после выпуска, мы обычно восстановим прежнее поведение, даже если это формально нарушит совместимость с поведением нового выпуска. При этом мы исходим из того, что регрессия затронет больше пользователей, чем поведение, появившееся в новом выпуске.
• Регрессии, обнаруженные с опозданием: Как описано в предыдущем разделе, если мы узнаем, что в значительно более раннем выпуске произошло непреднамеренное изменение редко используемой функции или сочетания функций, восстановление прежнего поведения может показаться регрессией тем, кто начал использовать OpenTofu позднее. Если мы сочтём, что исправление регрессии затронет больше пользователей, чем сама регрессия, то можем принять её как новое обещанное поведение.
• Непредвиденные ситуации: Хотя мы постарались учесть здесь различные конкретные исключительные ситуации, OpenTofu и процесс его разработки не изолированы от более широкого контекста. Поэтому мы должны учитывать, что могут возникнуть совершенно непредвиденные обстоятельства, влияющие на будущее OpenTofu. В таких ситуациях мы всегда будем делать всё возможное, чтобы свести к минимуму влияние на существующие модули и средства автоматизации.

Эти практические исключения нужны лишь для того, чтобы признать: всегда будут ситуации, которые невозможно охватить общими обещаниями о совместимости. Мы будем прибегать к таким исключениям только после тщательного рассмотрения и в крайнем случае.