Обещания совместимости 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 не существует, однако раздел «Конфигурация» в документации на веб-сайте 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, ARMv6 с разрядностью 32 бита и ARMv8 с разрядностью 64 бита (linux_amd64, linux_arm и linux_arm64 соответственно)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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