Релизы и техническое обслуживание

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

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

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

Каждый основной выпуск пакета Ansible сообщества принимает последнюю выпущенную версию каждой включённой коллекции и последнюю выпущенную версию ansible-core. Для конкретных расписаний и сроков см. дорожную карту для каждой версии. Основные релизы пакета 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 за советами по обновлению ваших playbook для запуска на более новых версиях 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 за советами по обновлению ваших playbook для запуска на более новых версиях ansible-core.

Вы можете установить ansible-core с помощью pip. См. Установка Ansible для получения подробной информации.

ansible-core поддержка Python контрольного узла

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

ansible-core поддержка Python целевого узла

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

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

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

ansible-core поддержка узлов PowerShell и Windows

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

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

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

Замораживание функциональности

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

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

Кандидаты в релиз

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

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

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

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

Процесс работы пакета Ansible community

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

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

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

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

Процесс работы ansible-core

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

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

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

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

Создание журналов изменений

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

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

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

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

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

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

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