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

В данном разделе описываются выпуски Ansible и ansible-core. Ansible — это пакет, который устанавливают большинство пользователей. ansible-core предназначен в первую очередь для разработчиков.

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

• Процесс разработки и технического обслуживания стабильных версий

  • Журналы изменений
  • Кандидаты в релиз
  • Замораживание новых функций

• Цикл устаревания

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

Цикл выпуска Ansible

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

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

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

Более старые, не поддерживаемые версии Ansible могут содержать неисправленные уязвимости безопасности (CVE).

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

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

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

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

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

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

Более старые, не поддерживаемые версии ansible-core могут содержать неисправленные уязвимости безопасности (CVE).

Вы можете ознакомиться с руководствами по переносу для получения советов по обновлению ваших Ansible playbooks для работы с новыми версиями.

Вы можете установить ansible-core с помощью pip. Подробности см. в Руководстве по установке Ansible.

В этой таблице приведены ссылки на заметки к выпуску для каждого основного выпуска ansible-core. Эти заметки к выпуску (журналы изменений) содержат даты и существенные изменения в каждом дополнительном выпуске.

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

Сообщество Ansible разрабатывает и поддерживает Ansible и ansible-core на GitHub.

Обновления коллекций (новые модули, плагины, функции и исправления ошибок) всегда будут интегрированы в следующую версию Ansible. Эта работа отслеживается в отдельных репозиториях коллекций.

Ansible и ansible-core предоставляют исправления ошибок и улучшения безопасности для последнего основного выпуска. Предыдущий основной выпуск ansible-core будет получать только исправления для проблем безопасности и критических ошибок. ansible-core применяет исправления безопасности только к выпускам, которые старше на два выпуска. Эта работа отслеживается на ветвях stable-<version> git.

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

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

Журналы изменений

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

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

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

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

Это дает сообществу Ansible возможность протестировать эти выпуски и сообщить об ошибках или проблемах, которые могут возникнуть.

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

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

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

Замораживание новых функций

Пока существует кандидат на выпуск, основные разработчики и разработчики сосредоточатся на исправлениях для кандидата в релиз.

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

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

Иногда нам нужно удалить функцию, обычно для того, чтобы переписать её, надеясь, что переработанная версия будет лучше. Для этого у нас есть цикл устаревания. Сначала мы помечаем функцию как «устаревшую». Это обычно сопровождается предупреждениями пользователю о причинах устаревания, о возможных альтернативах и о том, когда (в какой версии) мы планируем окончательно удалить функцию.

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

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

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

Цикл обычно охватывает 4 выпуска функций (2.x.y, где x обозначает выпуск функции, а y — выпуск исправления ошибок), поэтому функция обычно удаляется в 4-м выпуске после объявления об устаревании. Например, что-то устаревшее в 2.9 будет удалено в 2.13, предполагая, что мы не перейдём к 3.x до этого момента. Отслеживание связано с количеством релизов, а не с порядковым номером релиза.

Для модулей/плагинов мы сохраняем документацию после удаления для пользователей более старых версий.