Устаревшая разработка релизов FreeBSD | FreeBSD Documentation Portal
Description: В этом документе описывается подход, ранее использовавшийся командой разработки релизов FreeBSD для создания релизов операционной системы FreeBSD производственного качества
Keywords: Release,Engineering,Historical,FreeBSD

# Устаревшая разработка релизов FreeBSD

Этот перевод может быть устаревшим. Для того, чтобы помочь с переводом, пожалуйста, обратитесь к Сервер переводов FreeBSD.

товарные знаки

FreeBSD является зарегистрированным товарным знаком Фонда FreeBSD.

Intel, Celeron, EtherExpress, i386, i486, Itanium, Pentium и Xeon это торговые марки или зарегистрированные торговые марки Intel Corporation или ее дочерних компаний в Соединенных Штатах и других странах.

Многие из обозначений, используемые производителями и продавцами для обозначения своих продуктов, заявляются в качестве товарных знаков. Когда такие обозначения появляются в этом документе, и Проекту FreeBSD известно о товарном знаке, к обозначению добавляется знак “™” или “®”.

Аннотация

| Этот документ устарел и не точно описывает текущие процедуры выпуска релизов команды FreeBSD Release Engineering. Он сохранен в исторических целях. Текущие процедуры, используемые командой FreeBSD Release Engineering, доступны в статье FreeBSD Release Engineering.

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

## 1. Введение

Разработка FreeBSD — это очень открытый процесс. FreeBSD создаётся благодаря вкладу тысяч людей по всему миру. Проект FreeBSD предоставляет доступ к Subversion [1] для широкой публики, чтобы другие могли просматривать сообщения журнала, различия (патчи) между ветками разработки и другие улучшения производительности, которые предоставляет система управления исходным кодом. Это значительно помогло привлечь больше талантливых разработчиков в FreeBSD. Однако, я думаю, все согласятся, что хаос быстро воцарился бы, если бы право записи в основной репозиторий было открыто для всех в Интернете. Поэтому только «избранная» группа из почти 300 человек имеет право записи в репозиторий Subversion. Эти коммиттеры FreeBSD[2] обычно являются людьми, которые выполняют основную часть разработки FreeBSD. Выбранная группа разработчиков — Основная команда (Core Team)[3] — обеспечивает некоторый уровень руководства проектом.

Быстрый темп разработки `FreeBSD` делает основную ветку разработки непригодной для повседневного использования широкой публикой. В частности, требуются усилия по стабилизации для доведения системы разработки до релиза производственного качества. Для решения этого конфликта разработка продолжается по нескольким параллельным направлениям. Основная ветка разработки — это HEAD или trunk нашего дерева Subversion, известная как "FreeBSD-CURRENT" или сокращённо "-CURRENT".

Набор более стабильных ветвей поддерживается под названием "FreeBSD-STABLE" или сокращённо "-STABLE". Все ветви находятся в главном хранилище Subversion, которое поддерживается проектом FreeBSD. FreeBSD-CURRENT — это "передний край" разработки FreeBSD, куда сначала попадают все новые изменения. FreeBSD-STABLE — это ветвь разработки, на основе которой выпускаются основные релизы. Изменения попадают в эту ветвь с другой скоростью и с общим предположением, что они сначала попали в FreeBSD-CURRENT и были тщательно протестированы сообществом пользователей.

Термин stable в названии ветки относится к предполагаемой стабильности бинарного интерфейса приложений (ABI), которую гарантирует проект. Это означает, что пользовательское приложение, скомпилированное на более старой версии системы из той же ветки, будет работать на более новой системе из той же ветки. Стабильность ABI значительно улучшилась по сравнению с предыдущими выпусками. В большинстве случаев бинарные файлы со старых систем STABLE работают без изменений на более новых системах, включая HEAD, при условии, что не используются интерфейсы управления системой.

В промежуточный период между выпусками еженедельные снимки состояния системы автоматически создаются сборщиками FreeBSD Project и доступны для загрузки по адресу `https:/download.FreeBSD.org/snapshots/`. Широкое распространение бинарных снимков выпусков, а также склонность нашего сообщества пользователей следить за разработкой -STABLE с помощью Subversion и команды “make buildworld” [4] помогает поддерживать FreeBSD-STABLE в очень надёжном состоянии даже до того, как будут запущены мероприятия по обеспечению качества перед основным выпуском.

Помимо снимков установочных ISO, также предоставляются еженедельные образы виртуальных машин для использования с VirtualBox, qemu или другим популярным эмуляционным программным обеспечением. Образы виртуальных машин можно загрузить с `https://download.FreeBSD.org/snapshots/VM-IMAGES/`.

Образы виртуальных машин сжаты с помощью xz(1) и занимают примерно 150 МБ, а при подключении к виртуальной машине содержат разреженную файловую систему размером 10 ГБ.

Отчёты об ошибках и запросы функций постоянно отправляются пользователями в течение цикла выпуска. Сообщения о проблемах вносятся в нашу базу данных Bugzilla через веб-интерфейс, доступный по адресу https://www.freebsd.org/support/bugreports/.

Для обслуживания наиболее консервативных пользователей, начиная с FreeBSD 4.3, были введены индивидуальные ветки релизов. Эти ветки создаются незадолго до выпуска финального релиза. После выхода релиза на ветку вносятся только самые критические исправления безопасности и дополнения. Помимо обновлений исходного кода через Subversion, доступны бинарные патч-наборы для поддержания актуальности систем на ветках releng/X.Y.

### 1.1. Что описывает эта статья

Следующие разделы этой статьи описывают:

Процесс выпуска релиза

  Различные этапы процесса разработки релиза, предшествующие непосредственной сборке системы.

Сборка релиза

  Фактический процесс сборки.

Расширяемость

  Как базовый выпуск может быть расширен третьими сторонами.

Уроки

  Некоторые уроки, извлеченные в процессе выпуска FreeBSD 4.4.

Перспективы развития

  Перспективные направления развития.

## 2. Процесс выпуска релиза

Новые выпуски FreeBSD выходят из ветки -STABLE примерно с интервалом в четыре месяца. Процесс выпуска FreeBSD начинает набирать обороты за 70-80 дней до предполагаемой даты выпуска, когда инженер выпуска отправляет электронное письмо в списки рассылки разработчиков, напоминая им, что у них осталось всего 15 дней для интеграции новых изменений до заморозки кода. В это время многие разработчики выполняют так называемые "MFC-проверки".

MFC означает "Merge From CURRENT" и описывает процесс переноса проверенного изменения из нашей ветки разработки -CURRENT в ветку -STABLE. Политика проекта требует, чтобы любое изменение сначала было применено к основной ветке, а затем перенесено в ветки -STABLE после достаточного внешнего тестирования пользователями -CURRENT (ожидается, что разработчики тщательно проверят изменение перед внесением в -CURRENT, но невозможно для одного человека проверить все варианты использования универсальной операционной системы). Минимальный срок для MFC составляет 3 дня, который обычно используется только для тривиальных или критических исправлений ошибок.

### 2.1. Проверка кода

За шестьдесят дней до предполагаемого релиза репозиторий исходного кода переходит в режим «заморозки кода». В этот период все коммиты в ветку -STABLE должны быть одобрены `Группа Выпуска Релизов FreeBSD <re@FreeBSD.org>`. Процесс утверждения технически обеспечивается предкоммитным хуком. В этот период допускаются следующие виды изменений:

- Исправления ошибок.

- Обновления документации.

- Исправления, связанные с безопасностью, любого рода.

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

- Обновления драйверов от поставщиков.

- Любое дополнительное изменение, которое команда разработки релизов сочтет оправданным, учитывая потенциальный риск.

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

После того, как качество BETA-образов становится достаточно удовлетворительным и не планируется крупных и потенциально рискованных изменений, создаётся ветка релиза, и образы Release Candidate (RC) собираются из ветки релиза, вместо BETA-образов из ветки STABLE. Также снимается заморозка изменений в ветке STABLE, а ветка релиза переходит в режим "жёсткой заморозки кода", когда становится значительно сложнее обосновать новые изменения в системе, за исключением исправления серьезных ошибок или проблем безопасности.

### 2.2. Контрольный список финального выпуска

Когда несколько образов BETA станут доступны для широкого тестирования и все основные проблемы будут устранены, можно приступать к финальной "доводке" выпуска.

#### 2.2.1. Создание ветки релиза

| Во всех примерах ниже `$FSVN` указывает на расположение репозитория Subversion FreeBSD, `svn+ssh://svn.FreeBSD.org/base/`.

Расположение веток FreeBSD в Subversion описано в Руководстве коммиттера. Первым шагом в создании ветки является определение ревизии исходников `stable/X`, от которой вы хотите сделать ответвление.

    # svn log -v $FSVN/stable/9

Следующий шаг — создание ветки релиза

    # svn cp $FSVN/stable/9@REVISION $FSVN/releng/9.2

Эту ветку можно извлечь:

    # svn co $FSVN/releng/9.2 src

| Создание ветки `releng` и тегов `release` выполняется командой Release Engineering Team.

#### 2.2.2. Увеличение номера версии

Перед тем как финальный выпуск может быть помечен, собран и выпущен, следующие файлы должны быть изменены, чтобы отражать корректную версию FreeBSD:

- doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml

- doc/en_US.ISO8859-1/books/porters-handbook/book.xml

- doc/en_US.ISO8859-1/htdocs/cgi/ports.cgi

- ports/Tools/scripts/release/config

- doc/shared/xml/freebsd.ent

- src/Makefile.inc1

- src/UPDATING

- src/gnu/usr.bin/groff/tmac/mdoc.local

- src/release/Makefile

- src/release/doc/en_US.ISO8859-1/shared/xml/release.dsl

- src/release/doc/shared/examples/Makefile.relnotesng

- src/release/doc/shared/xml/release.ent

- src/sys/conf/newvers.sh

- src/sys/sys/param.h

- src/usr.sbin/pkg_install/add/main.c

- doc/en_US.ISO8859-1/htdocs/search/opensearch/man.xml

Заметки о выпуске и файлы с опечатками также необходимо адаптировать для нового выпуска (в ветке выпуска) и соответствующим образом обрезать (в ветке stable/current):

- src/release/doc/en_US.ISO8859-1/relnotes/common/new.xml

- src/release/doc/en_US.ISO8859-1/errata/article.xml

В Sysinstall следует добавить информацию о количестве доступных портов и объёме дискового пространства, необходимого для коллекции портов. [5] В настоящее время эта информация хранится в src/usr.sbin/bsdinstall/dist.c.

После сборки выпуска следует обновить ряд файлов, чтобы объявить о выпуске. Эти файлы находятся относительно `head/` в поддереве `doc/` Subversion.

- share/images/articles/releng/branches-relengX.pic

- head/shared/xml/release.ent

- en_US.ISO8859-1/htdocs/releases/*

- en_US.ISO8859-1/htdocs/releng/index.xml

- share/xml/news.xml

Кроме того, обновите файл "Генеалогическое древо BSD":

- src/shared/misc/bsd-family-tree

#### 2.2.3. Создание тега релиза

Когда финальный выпуск будет готов, следующая команда создаст тег `release/9.2.0`.

    # svn cp $FSVN/releng/9.2 $FSVN/release/9.2.0

Менеджеры документации и портов ответственны за добавление тега `tags/RELEASE_9_2_0` в соответствующие деревья.

Когда команда Subversion `svn cp` используется для создания тега релиза (release tag), это идентифицирует исходный код на определённый момент времени. Создавая теги, мы гарантируем, что будущие сборщики релизов всегда смогут использовать тот же исходный код, который использовался для создания официальных релизов проекта FreeBSD.

## 3. Сборка релиза

Сборка "релизов" FreeBSD может быть выполнена любым пользователем, имеющим быстрый компьютер и доступ к репозиторию исходного кода. (Это должно быть доступно каждому, так как мы предоставляем доступ через Subversion! Подробности см. в разделе Subversion в Руководстве.) Единственное специальное требование — доступность устройства md(4). Если устройство не загружено в ваше ядро, то модуль ядра должен автоматически загрузиться при выполнении mdconfig(8) во время этапа создания загрузочного носителя. Все необходимые инструменты для сборки релиза доступны в репозитории Subversion в src/release. Эти инструменты предназначены для обеспечения единообразного способа сборки релизов FreeBSD. Полный релиз может быть собран всего одной командой, включая создание ISO-образов, пригодных для записи на CDROM или DVD, а также каталога для установки по FTP. release(7) полностью документирует скрипт `src/release/generate-release.sh`, который используется для сборки релиза. `generate-release.sh` является обёрткой для цели Makefile: `make release`.

### 3.1. Сборка релиза

release(7) документирует точные команды, необходимые для сборки релиза FreeBSD. Следующая последовательность команд может собрать релиз 9.2.0:

    # cd /usr/src/release
    # sh generate-release.sh release/9.2.0 /local3/release

После выполнения этих команд все подготовленные файлы релиза будут доступны в каталоге /local3/release/R.

Файл Makefile для выпуска можно разбить на несколько отдельных этапов.

- Создание изолированного окружения системы в отдельной иерархии каталогов с помощью “make installworld”.

- Извлечение из Subversion чистой версии исходного кода системы, документации и портов в иерархию сборки релиза.

- Заполнение каталогов /etc и /dev в chroot-окружении.

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

- Запуск `make world` в окружении `chroot`.

- Сборка связанных с Kerberos бинарных файлов.

- Сборка ядра GENERIC.

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

- Сборка и установка инструментария для документации, необходимого для преобразования исходников документации (SGML) в HTML и текстовые документы, которые будут поставляться с релизом.

- Сборка и установка непосредственно документации (руководства пользователя, учебные пособия, примечания к выпуску, списки совместимого оборудования и так далее).

- Создание распространяемых tar-архивов с бинарными файлами и исходными кодами.

- Создание иерархии установки FTP.

- (необязательно) Создание ISO-образов для носителей CDROM/DVD.

Для получения дополнительной информации о инфраструктуре сборки релизов, обратитесь к release(7).

| Важно удалить все специфичные для сайта настройки из /etc/make.conf. Например, было бы неразумно распространять бинарные файлы, собранные на системе с установленным `CPUTYPE` для конкретного процессора.

### 3.2. Предоставленное программное обеспечение ("порты")

Коллекция портов FreeBSD представляет собой набор из более чем 36000 сторонних программных пакетов, доступных для FreeBSD. `Группа Менеджеров Дерева Портов FreeBSD <portmgr@FreeBSD.org>` отвечает за поддержание согласованного дерева портов, которое может быть использовано для создания бинарных пакетов, поставляемых с официальными выпусками FreeBSD.

### 3.3. Релизные ISO-образы

Начиная с FreeBSD 4.4, проект FreeBSD решил выпустить все четыре образа ISO, которые ранее продавались на «официальных» дистрибутивах CDROM от BSDi/Wind River Systems/FreeBSD Mall. Каждый из четырёх дисков должен содержать файл README.TXT, объясняющий содержимое диска, файл CDROM.INF, предоставляющий метаданные для диска, чтобы bsdinstall(8) мог проверить и использовать содержимое, и файл filename.txt, содержащий манифест диска. Этот манифест можно создать простой командой:

    /stage/cdrom# find . -type f | sed -e 's/^\.\///' | sort > filename.txt

Конкретные требования для каждого CD приведены ниже.

#### 3.3.1. Диск 1

Первый диск почти полностью создаётся командой `make release`. Единственные изменения, которые следует внести в каталог disc1, — это добавление каталога tools и как можно большего количества популярных сторонних программных пакетов, которые поместятся на диск. В каталоге tools содержится программное обеспечение, позволяющее пользователям создавать установочные дискеты из других операционных систем. Этот диск должен быть загрузочным, чтобы пользователям современных ПК не требовалось создавать установочные дискеты.

Если требуется включить пользовательское ядро FreeBSD, необходимо обновить bsdinstall(8) и release(7), чтобы включить инструкции по установке. Соответствующий код содержится в src/release и src/usr.sbin/bsdinstall. В частности, потребуется обновить файл src/release/Makefile, а также dist.c, dist.h, menus.c, install.c и Makefile в каталоге src/usr.sbin/bsdinstall. При желании можно также обновить bsdinstall.8.

#### 3.3.2. Диск 2

Второй диск также в основном создаётся командой `make release`. Этот диск содержит «живую файловую систему», которая может использоваться через bsdinstall(8) для диагностики установки FreeBSD. Этот диск должен быть загрузочным и также содержать сжатую копию репозитория CVS в каталоге CVSROOT и демонстрационные версии коммерческого ПО в каталоге commerce.

#### 3.3.3. Поддержка нескольких томов

Sysinstall поддерживает установку пакетов с нескольких томов. Для этого каждый диск должен содержать файл INDEX, в котором перечислены все пакеты на всех томах набора, а также дополнительное поле, указывающее, на каком именно томе находится конкретный пакет. Каждый том в наборе также должен иметь установленную переменную `CD_VOLUME` в файле cdrom.inf, чтобы bsdinstall мог определить, какой том является каким. Когда пользователь пытается установить пакет, которого нет на текущем диске, bsdinstall предложит ему вставить соответствующий диск.

## 4. Распространение

### 4.1. Сайты FTP

Когда выпуск тщательно протестирован и упакован для распространения, необходимо обновить главный FTP-сайт. Официальные публичные FTP-сайты FreeBSD являются зеркалами главного сервера, который доступен только другим FTP-сайтам. Этот сервер известен как `ftp-master`. Когда выпуск готов, следующие файлы должны быть изменены на `ftp-master`:

/pub/FreeBSD/releases/arch/X.Y-RELEASE/

  Устанавливаемый каталог FTP, полученный в результате выполнения `make release`.

/pub/FreeBSD/ports/arch/packages-X.Y-release/

  Полная сборка пакетов для этого выпуска.

/pub/FreeBSD/releases/arch/X.Y-RELEASE/tools

  Символическая ссылка на ../../../tools.

/pub/FreeBSD/releases/arch/X.Y-RELEASE/packages

  Символическая ссылка на ../../../ports/arch/packages-X.Y-release.

/pub/FreeBSD/releases/arch/ISO-IMAGES/X.Y/X.Y-RELEASE-arch-*.iso

  Образы ISO. Символ "*" обозначает disc1, disc2 и так далее. Только если существует disc1 и есть альтернативный первый установочный CD (например, упрощённая установка без графической оболочки), может также присутствовать mini.

Для получения дополнительной информации об архитектуре зеркал распространения FTP-сайтов FreeBSD, пожалуйста, ознакомьтесь со статьей Поддержка зеркал FreeBSD.

Может потребоваться от нескольких часов до двух дней после обновления `ftp-master`, прежде чем большинство FTP-сайтов Tier-1 получат новое программное обеспечение, в зависимости от того, был ли загружен набор пакетов одновременно. Крайне важно, чтобы инженеры по выпуску скоординировались с Администраторы зеркальных сайтов FreeBSD перед объявлением общей доступности нового программного обеспечения на FTP-сайтах. В идеале набор пакетов для выпуска должен быть загружен как минимум за четыре дня до дня выпуска. Выпускные файлы должны быть загружены за 24–48 часов до запланированного времени выпуска с отключёнными разрешениями для "других" пользователей. Это позволит зеркальным сайтам загрузить их, но широкая публика не сможет скачать их с зеркальных сайтов. Письмо должно быть отправлено в Администраторы зеркальных сайтов FreeBSD в момент публикации выпускных файлов, уведомляя о том, что выпуск подготовлен, и указывая время, когда зеркальные сайты должны начать разрешать доступ. Обязательно укажите часовой пояс для указанного времени, например, относительно GMT.

### 4.2. Репликация CD-ROM

Скоро: Советы по отправке ISO-образов FreeBSD репликатору и меры по обеспечению качества.

## 5. Расширяемость

Хотя FreeBSD представляет собой законченную операционную систему, ничто не обязывает вас использовать её именно в том виде, в каком мы упаковали её для распространения. Мы постарались разработать систему максимально расширяемой, чтобы она могла служить платформой для создания других коммерческих продуктов. Единственное «правило», которое у нас есть на этот счёт, — если вы собираетесь распространять FreeBSD с существенными изменениями, мы рекомендуем документировать ваши улучшения! Сообщество FreeBSD может оказывать поддержку только пользователям того программного обеспечения, которое мы предоставляем. Мы, безусловно, приветствуем инновации, такие как продвинутые инструменты установки и администрирования, но не можем отвечать на вопросы о них.

### 5.1. Скриптинг `bsdinstall`

Инструмент установки и настройки системы FreeBSD, bsdinstall(8), может быть настроен для автоматизированной установки на крупных площадках. Эта функциональность может использоваться совместно с Intel® PXE [6] для загрузки систем по сети.

## 6. Уроки, извлеченные из FreeBSD 4.4

Процесс разработки релиза 4.4 официально начался 1 августа 2001 года. После этой даты все коммиты в ветку `RELENG_4` FreeBSD должны были быть явно одобрены `Группа Выпуска Релизов FreeBSD <re@FreeBSD.org>`. Первый релиз-кандидат для архитектуры x86 был выпущен 16 августа, за ним последовали ещё 4 релиз-кандидата, что привело к финальному релизу 18 сентября. Сотрудник по безопасности был очень вовлечён в последнюю неделю процесса, так как несколько проблем безопасности было обнаружено в ранних релиз-кандидатах. Всего за чуть более месяца было отправлено более 500 писем `Группа Выпуска Релизов FreeBSD <re@FreeBSD.org>`.

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

## 7. Перспективы развития

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

- Параллелизм — Некоторые этапы сборки релиза действительно "тривиально параллельны". Большинство задач очень интенсивно используют ввод-вывод, поэтому наличие нескольких высокоскоростных дисков важнее, чем использование нескольких процессоров для ускорения процесса `make release`. Если в среде chroot(2) разные иерархии размещены на разных дисках, то выгрузка CVS для деревьев ports и doc может происходить одновременно с выполнением `make world` на другом диске. Использование RAID (аппаратного или программного) может значительно сократить общее время сборки.

- Кросс-сборка релизов - Сборка релиза для IA-64 или Alpha на x86 оборудовании? `make TARGET=ia64 release`.

- Регрессионное тестирование - Нам необходимы более совершенные автоматизированные тесты на корректность для FreeBSD.

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

## 8. Благодарности

Я хотел бы поблагодарить Джордана Хаббарда за предоставленную мне возможность взять на себя часть обязанностей по управлению выпусками для FreeBSD 4.4, а также за всю его работу на протяжении многих лет, которая сделала FreeBSD такой, какая она есть сегодня. Конечно, выпуск не состоялся бы без всей работы, связанной с выпуском, выполненной `Satoshi Asami <asami@FreeBSD.org>`, `Steve Price <steve@FreeBSD.org>`, `Bruce A. Mah <bmah@FreeBSD.org>`, `Nik Clayton <nik@FreeBSD.org>`, `David O’Brien <obrien@FreeBSD.org>`, `Kris Kennaway <kris@FreeBSD.org>`, `John Baldwin <jhb@FreeBSD.org>` и остальным сообществом разработчиков FreeBSD. Я также хотел бы поблагодарить `Rodney W. Grimes <rgrimes@FreeBSD.org>`, `Poul-Henning Kamp <phk@FreeBSD.org>` и других, кто работал над инструментами управления выпусками в самые ранние дни FreeBSD. На эту статью повлияли документы по управлению выпусками от CSRG [7], проекта NetBSD [8] и заметки Джона Болдуина с предложениями по процессу управления выпусками. [9]

1. Subversion, http://subversion.apache.org
2. коммиттеры FreeBSD
3. Основная команда FreeBSD
4. Пересборка world
5. Коллекция портов FreeBSD https://ports.FreeBSD.org
6. Запуск системы по сети (PXE) без использования локальных накопителей
7. Маршалл Кирк МакКузик, Майкл Дж. Карелс и Кит Бостик: Управление выпусками 4.3BSD
8. Документация разработчика NetBSD: Управление выпусками http://www.NetBSD.org/developers/releng/index.html
9. Предложение Джона Болдуина по управлению выпусками FreeBSD https://people.FreeBSD.org/~jhb/docs/releng.txt

Изменено: 18 июня 2026 г. by Alexander Ziaee