Выпуски и сопровождение

Цикл выпуска пакета сообщества Ansible

Команда сообщества Ansible обычно выпускает две основные версии пакета сообщества в год по гибкому графику, который следует за выпуском ansible-core. Этот цикл можно продлить, чтобы обеспечить надлежащую реализацию и тестирование более масштабных изменений до выхода нового выпуска. Сведения о предстоящих выпусках см. в разделе Дорожная карта Ansible. Между основными версиями каждые четыре недели выпускается новая минорная версия пакета сообщества Ansible. Минорные выпуски включают новые обратно совместимые функции, модули и плагины, а также исправления ошибок.

Начиная с версии 2.10 команда сообщества Ansible гарантирует сопровождение только одной основной версии пакета сообщества за раз. Например, после выпуска Ansible 4.0.0 команда прекратит выпускать новые версии 3.x. При желании участники сообщества могут сопровождать старые версии.

Каждый основной выпуск пакета сообщества Ansible включает последнюю выпущенную версию каждой входящей в него коллекции и последнюю выпущенную версию ansible-core. Точные графики и сроки для каждой версии см. в разделе Дорожная карта Ansible. Основные выпуски пакета сообщества Ansible могут содержать несовместимые изменения в модулях и других плагинах входящих в него коллекций, а также в основных функциях.

Пакет сообщества Ansible следует правилам семантического версионирования. Минорные выпуски пакета сообщества Ansible принимают только обратно совместимые изменения входящих в него коллекций, то есть не основные выпуски коллекций. Коллекции также должны использовать семантическое версионирование, поэтому их номера версий отражают это правило. Например, если Ansible 3.0.0 выпускается с community.general 2.0.0, то все минорные выпуски Ansible 3.x (например, Ansible 3.1.0 или Ansible 3.5.0) должны включать версию 2.x community.general (например, 2.8.0 или 2.9.5), а не 3.x.x или более поздние основные версии.

Работа над коллекциями отслеживается в репозиториях соответствующих коллекций.

Рекомендации по обновлению плейбуков для работы с новыми версиями Ansible см. в руководствах по переносу пакета Ansible. Для Ansible 2.10 и более поздних выпусков пакет Ansible можно установить с помощью pip. Подробности см. в разделе Установка Ansible. Старые выпуски Ansible можно скачать с сайта https://releases.ansible.com/ansible/.

Списки изменений сообщества Ansible

В этой таблице приведены ссылки на списки изменений для каждого основного выпуска Ansible. В этих списках изменений указаны даты и существенные изменения в каждом минорном выпуске.

Цикл выпуска ansible-core

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

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

Рекомендации по обновлению плейбуков для работы с новыми версиями ansible-core см. в руководствах по переносу Ansible Core.

Установить ansible-core можно с помощью pip. Подробности см. в разделе Установка Ansible.

Поддержка Python на управляющем узле в ansible-core

Начиная с версии ansible-core 2.12, каждый выпуск поддерживает на управляющем узле три последние выпущенные версии Python.

Поддержка Python на целевом узле в ansible-core

Начиная с версии ansible-core 2.16, каждый выпуск поддерживает на целевом узле:

• 6 последних выпущенных версий Python.
• 7 последних выпущенных версий Python в каждом 6-м выпуске ansible-core (2.16, 2.22 и т. д.)

Поддержка Python 2.7 включена в версию ansible-core 2.16 и более ранние версии.

Поддержка Windows на целевом узле в ansible-core

ansible-core поддерживает целевые узлы Windows в соответствии с политикой жизненного цикла Windows. Поддержка версии Windows на целевом узле прекращается, когда эта версия достигает даты окончания расширенной поддержки. Например, расширенная поддержка Windows Server 2012 и 2012 R2 завершилась 10 октября 2023 года, а для Windows Server 2016 она завершается 12 января 2027 года. Поддержка Windows не соответствует трёхлетней поддержке расширенных обновлений безопасности (ESU) от Microsoft. Это платный вариант поддержки продуктов, для которых истёк обычный срок поддержки Microsoft.

Поддержка PowerShell на целевом узле в ansible-core

ansible-core в Windows поддерживает Windows PowerShell 5.1, который входит в состав Windows. Начиная с версии ansible-core 2.21, каждый выпуск также поддерживает на целевом узле последнюю версию PowerShell 7.x с долгосрочной поддержкой (LTS).

Для PowerShell 7 предусмотрен двухлетний цикл выпуска версий LTS, каждая из которых поддерживается в течение трёх лет. Большинство выпусков Ansible соответствуют одной версии PowerShell LTS. Однако каждый 5-й выпуск Ansible совпадает с переходным периодом между версиями PowerShell LTS и поддерживает обе версии LTS — предыдущую и новую:

• Предыдущая версия LTS достигает конца жизненного цикла в течение периода сопровождения выпуска Ansible
• Новая версия LTS находится в предварительной версии на момент выпуска Ansible и становится общедоступной примерно во время выпуска или через несколько месяцев

Такая параллельная поддержка позволяет пользователям спланировать переход на новую версию PowerShell LTS, пока Microsoft продолжает поддерживать предыдущую.

Следующим выпуском с несколькими версиями LTS после этого станет 2.28, который будет поддерживать PowerShell 7.8 и 7.10.

Матрица поддержки ansible-core

В этой таблице приведены ссылки на списки изменений для каждого основного выпуска ansible-core. В этих списках изменений указаны даты и существенные изменения в каждом минорном выпуске. Указанные даты обозначают начало цикла сопровождения.

Версионирование ansible-core

Проект ansible-core использует историческую схему версионирования, наиболее близкую к схеме, используемой в Python.

Эта схема соответствует формату X.Y.Z, который подробно описан ниже.

Заморозка добавления функций

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

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

Кандидаты на выпуск

Перед каждым новым основным выпуском Ansible или ansible-core мы создаём как минимум одного кандидата на выпуск. Кандидаты на выпуск позволяют сообществу Ansible опробовать новые функции, проверить существующие плейбуки и сообщить об обнаруженных ошибках и проблемах.

Ansible и ansible-core помечают первый кандидат на выпуск (RC1); обычно на его проверку отводится пять рабочих дней. Если за это время не обнаружено серьёзных ошибок или проблем, кандидат на выпуск становится финальным выпуском.

Если у первого кандидата есть серьёзные проблемы, команда и сообщество исправляют их и помечают второго кандидата на выпуск (RC2). Проверка второго кандидата длится меньше, чем первого. Если в течение двух рабочих дней после выпуска RC2 о проблемах не сообщается, второй кандидат становится финальным выпуском.

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

Рабочий процесс пакета сообщества Ansible

Сообщество Ansible разрабатывает и сопровождает функции и возможности, включённые в пакет сообщества Ansible, в репозиториях коллекций. Рабочий процесс выглядит следующим образом:

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

Как правило, мы не выпускаем исправления для несопровождаемых версий пакета сообщества Ansible, хотя в некоторых случаях могут быть исключения для критических проблем.

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

Рабочий процесс ansible-core

Сообщество Ansible разрабатывает и сопровождает ansible-core на GitHub. Рабочий процесс выглядит следующим образом:

• Разработчики добавляют новые функции и исправления ошибок в ветку devel.
• К каждой новой функции и каждому исправлению ошибки добавляется фрагмент списка изменений с описанием работы.
• Команда разработки переносит исправления ошибок в одну, две или три стабильные ветки в зависимости от серьёзности ошибки. Новые функции в эти ветки не переносятся.
• Инженеры выпуска каждые четыре недели создают минорный выпуск каждой сопровождаемой версии, чтобы последние исправления ошибок были доступны пользователям.
• В конце периода разработки инженеры выпуска вводят заморозку добавления функций, и начинается работа над новым выпуском.

Как правило, мы не выпускаем исправления для несопровождаемых версий ansible-core, хотя в некоторых случаях могут быть исключения для критических проблем.

Дополнительные сведения о добавлении функций и исправлении ошибок в ansible-core см. в разделе Цикл разработки Ansible.

Создание списков изменений

Списки изменений создаются на основе фрагментов. При добавлении новых функций в существующие модули и плагины или исправлении ошибок создайте фрагмент списка изменений с описанием изменения. Для новых модулей и плагинов запись в списке изменений не требуется: сведения о них будут созданы на основе документации модуля.

Для добавления фрагментов списка изменений в коллекции пакета сообщества Ansible рекомендуем использовать утилиту antsibull-changelog.

Сведения о добавлении фрагментов списка изменений для новых функций и исправлений ошибок в ansible-core см. в разделе примеры и инструкции по работе со списками изменений в руководстве сообщества.

Цикл устаревания пакета сообщества Ansible

Поскольку Ansible — это пакет отдельных коллекций, цикл устаревания зависит от сопровождающих коллекций. Мы рекомендуем сопровождающим коллекций объявлять функцию устаревшей в одной основной версии Ansible и не удалять её в течение года или как минимум до следующей основной версии Ansible. Например, объявить функцию устаревшей в версии 3.1.0 и не удалять её до версии 5.0.0 или, в самом раннем случае, до версии 4.0.0. Коллекции должны использовать семантическое версионирование, при котором основная версия коллекции не может меняться в рамках одной основной версии Ansible. Поэтому удаление не должно происходить раньше следующего основного выпуска пакета сообщества Ansible. Это решение принимает каждый сопровождающий коллекции, и гарантировать соблюдение этого правила нельзя.

Цикл устаревания ansible-core

Цикл устаревания в ansible-core обычно охватывает 4 выпуска с новыми функциями (2.x., где x обозначает выпуск с новыми функциями). Обычно функцию удаляют в 4-м выпуске после объявления о её устаревании. Например, функция, объявленная устаревшей в версии 2.10, будет удалена в версии 2.13. Отсчёт ведётся по количеству выпусков, а не по их номерам. Хотя это стандартный порядок, в зависимости от особенностей использования или срочности удаления цикл устаревания функции или поведения может быть длиннее или короче. Непреднамеренные или недокументированные функции могут быть удалены без цикла устаревания. В данном контексте непреднамеренные функции — это исключительно возникающие свойства, не предусмотренные планом выпуска.