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

• Цикл выпуска
• Статус выпуска
• Процедура разработки и технического обслуживания стабильных версий
  • Журналы изменений
  • Кандидаты в релиз
  • Замораживание функций
• Цикл устаревания

Цикл выпуска

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

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

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

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

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

Статус выпуска

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

Вы можете загрузить релизы по адресу https://releases.ansible.com/ansible/.

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

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

Новые модули, плагины, функции и исправления ошибок всегда будут интегрированы в следующую основную версию Ansible. Эта работа отслеживается в ветке devel git.

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

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

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

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

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

Старые версии записывали изменения в stable-<version>/CHANGELOG.md. Например, вот журнал изменений для 2.4.

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

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

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

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

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

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

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

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

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

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

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

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

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