Подготовка релизов FreeBSD

Хотя мягкая заморозка кода не является полной заморозкой дерева, команда FreeBSD Release Engineering Team просит отдавать приоритет исправлению ошибок в существующей кодовой базе перед добавлением новых функций.

Мягкая заморозка кода не требует подтверждений коммитов в ветку.

Замораживание кода означает момент времени, когда все коммиты в ветку требуют явного одобрения от FreeBSD Release Engineering Team.

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

Для обеспечения утверждения коммитов командой FreeBSD Release Engineering Team, команда Release Engineering должна утверждать любые изменения в ветке. В этом случае журнал коммитов должен содержать строку Approved by: re (логин), где "логин" — это идентификатор утверждающего.

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

Когда график цикла выпуска становится доступным, эти файлы необходимо обновить, чтобы включить различные функции на веб-сайте проекта FreeBSD:

При переходе от PRERELEASE к BETA эти файлы необходимо обновить, чтобы включить блок "Help Test (Помогите протестировать)" на странице загрузки. Все файлы указаны относительно head/ в репозитории doc:

После создания ветки releng/13.0 необходимо добавить различные документы, связанные с выпуском, в репозиторий doc/.

Для каждой сборки в течение цикла выпуска файлы MANIFEST, содержащие SHA256 для различных наборов дистрибутива, таких как base.txz, kernel.txz и других, добавляются в порт misc/freebsd-release-manifests. Это позволяет другим утилитам, кроме , таким как ports-mgmt/poudriere, безопасно использовать эти наборы дистрибутива, предоставляя механизм для проверки контрольных сумм.

Начиная с цикла выпуска FreeBSD 10.0-RELEASE, было введено понятие сборок “ALPHA”. В отличие от сборок BETA и RC, сборки ALPHA не включены в график выпуска FreeBSD.

Идея сборок ALPHA заключается в предоставлении регулярных сборок FreeBSD до создания ветки stable/.

Снимки состояния ALPHA FreeBSD должны собираться примерно раз в неделю.

Для первой сборки ALPHA значение BRANCH в sys/conf/newvers.sh необходимо изменить с CURRENT на ALPHA1. Для последующих сборок ALPHA увеличивайте каждое значение ALPHAN на единицу.

См. crossref:freebsd-releng[releng-building, Сборка установочных носителей FreeBSD] для получения информации о сборке образов ALPHA.

При создании ветки stable/ необходимо внести несколько изменений как в новой ветке stable/, так и в ветке main. Указанные файлы относятся к корню репозитория. Чтобы создать новую ветку stable/13 в Git:

После создания ветки stable/13 внесите следующие изменения:

Затем в ветке main, которая теперь станет новой основной версией:

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

После периода мягкой заморозки следующая фаза цикла выпуска — это заморозка кода. На этом этапе все коммиты в стабильную ветку требуют явного одобрения от FreeBSD Release Engineering Team. Это контролируется {git-admin-email}, который управляет репозиторием.

После вступления в силу заморозки кода следующая сборка из ветки помечается как BETA1. Это делается путём изменения значения BRANCH в файле sys/conf/newvers.sh с PRERELEASE на BETA1.

После этого начинается первая сборка BETA. Последующие сборки BETA не требуют обновления каких-либо файлов, кроме sys/conf/newvers.sh, с увеличением номера сборки BETA.

Когда первая сборка RC (Release Candidate) готова к началу, создается ветка releng/. Это многоэтапный процесс, который должен выполняться в определенном порядке, чтобы избежать аномалий, таких как пересечения значений __FreeBSD_version, например. Указанные ниже пути относятся к корню репозитория. Порядок коммитов и что нужно изменить:

Затем {git-admin-email} добавляет новых утверждающих для ветки releng, как это было сделано для ветки stable.

Теперь, когда существуют два новых значения __FreeBSD_version, также обновите файл ~/documentation/content/en/books/porters-handbook/versions/chapter.adoc в репозитории проекта документации.

После завершения первой сборки RC и её тестирования ветку stable/ можно «разморозить» с помощью {git-admin-email}.

После появления первой версии RC необходимо отправить письмо команде FreeBSD Bugmeister Team, чтобы добавить новую версию FreeBSD -RELEASE в список versions, доступный в выпадающем меню трекера ошибок.

До выхода FreeBSD 9.0-RELEASE файл src/release/Makefile был обновлен для поддержки , а скрипт src/release/generate-release.sh был добавлен в качестве обертки для автоматизации вызова целей.

До выхода FreeBSD 9.2-RELEASE был представлен src/release/release.sh, который, основываясь на src/release/generate-release.sh, включал поддержку указания конфигурационных файлов для переопределения различных опций и переменных окружения. Поддержка конфигурационных файлов обеспечила возможность кросс-сборки каждого архитектурного варианта для релиза путем указания отдельного конфигурационного файла для каждого вызова.

В качестве краткого примера использования src/release/release.sh для сборки одного релиза в /scratch:

В качестве краткого примера использования src/release/release.sh для сборки единого кросс-собранного выпуска с использованием другого целевого каталога, создайте пользовательский release.conf, содержащий:

Затем выполните src/release/release.sh следующим образом:

См. src/release/release.conf.sample для получения дополнительных сведений и примеров использования.

В течение цикла выпуска копии файлов CHECKSUM.SHA512 и CHECKSUM.SHA256 для каждой архитектуры сохраняются во внутреннем репозитории FreeBSD Release Engineering Team, а также включаются в различные рассылки с объявлениями. Каждый файл MANIFEST, содержащий хеши base.txz, kernel.txz и других, также добавляется в пакет misc/freebsd-release-manifests в Коллекции портов.

В подготовке к сборке выпуска необходимо обновить несколько файлов:

После сборки окончательного RELEASE, ветка releng/13.0 помечается как release/13.0.0, используя ревизию, из которой был собран RELEASE. Аналогично созданию веток stable/13 и releng/13.0, это делается с помощью git tag. Из корня репозитория:

Этап подготовки (staging) снимков и выпусков FreeBSD — это двухэтапный процесс:

Как только образы размещены в /archive/tmp/, они готовы к публикации путем размещения в /archive/pub/FreeBSD. Для уменьшения времени распространения используются жесткие ссылки из /archive/tmp в /archive/pub/FreeBSD.

Однако есть оговорка: после этого необходимо использовать rsync для исправления символических ссылок в pub/FreeBSD/snapshots/ISO-IMAGES, которые будут заменены на жёсткие ссылки, что увеличит время распространения.

Как пользователь archive:

Замените снимки на релизы там, где это уместно.

По мере приближения цикла выпуска к завершению часто появляются несколько кандидатов в EN (Errata Notice — уведомления об ошибках) для устранения проблем, обнаруженных на поздних этапах цикла. После выпуска FreeBSD Release Engineering Team и FreeBSD Security Team пересматривают изменения, которые не были одобрены до финального выпуска, и, в зависимости от масштаба рассматриваемого изменения, могут выпустить EN.

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

Заполненный шаблон уведомления об ошибке следует отправить по электронной почте вместе с патчем для ветки releng/ или списком ревизий из ветки stable/.

Для запросов на уведомления об ошибках (Errata Notice), поступающих сразу после выпуска, запрос следует отправлять по электронной почте как в FreeBSD Release Engineering Team, так и в FreeBSD Security Team. После того как ветка releng/ передана FreeBSD Security Team, как описано в Передача FreeBSD Security Team, запросы на уведомления об ошибках следует направлять в FreeBSD Security Team.

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

Когда выпуск достигает конца жизненного цикла, ссылки на этот выпуск должны быть удалены и/или обновлены на веб-сайте: