# FreeBSD Release Engineering

### Murray Stokely

`<murray@FreeBSD.org>`

$FreeBSD: release/8.4.0/en_US.ISO8859-1/articles/releng/article.xml 41264 2013-03-18 23:18:12Z rodrigc $

$FreeBSD: release/8.4.0/en_US.ISO8859-1/articles/releng/article.xml 41264 2013-03-18 23:18:12Z rodrigc $

Legal Notice

> Warning: 2013/02/26: This document is outdated and does not accurately describe the current release procedures of the FreeBSD Release Engineering team. The FreeBSD Release Engineering team is currently reviewing this document and will publish updated content soon.

This paper describes the approach used by the FreeBSD release engineering team to make production quality releases of the FreeBSD Operating System. It details the methodology used for the official FreeBSD releases and describes the tools available for those interested in producing customized FreeBSD releases for corporate rollouts or commercial productization.

[ Split HTML / Single HTML ]

# 1 Introduction

The development of FreeBSD is a very open process. FreeBSD is comprised of contributions from thousands of people around the world. The FreeBSD Project provides Subversion [1] access to the general public so that others can have access to log messages, diffs (patches) between development branches, and other productivity enhancements that formal source code management provides. This has been a huge help in attracting more talented developers to FreeBSD. However, I think everyone would agree that chaos would soon manifest if write access was opened up to everyone on the Internet. Therefore only a “select” group of nearly 300 people are given write access to the Subversion repository. These committers [2] are responsible for the bulk of FreeBSD development. An elected Core Team [3] of very senior developers provides some level of direction over the project.

The rapid pace of FreeBSD development leaves little time for polishing the development system into a production quality release. To solve this dilemma, development continues on two parallel tracks. The main development branch is the HEAD or trunk of our Subversion tree, known as “FreeBSD-CURRENT” or “-CURRENT” for short.

A more stable branch is maintained, known as “FreeBSD-STABLE” or “-STABLE” for short. Both branches live in a master Subversion repository on a machine maintained by the FreeBSD Project. FreeBSD-CURRENT is the “bleeding-edge” of FreeBSD development where all new changes first enter the system. FreeBSD-STABLE is the development branch from which major releases are made. Changes go into this branch at a different pace, and with the general assumption that they have first gone into FreeBSD-CURRENT and have been thoroughly tested by our user community.

In the interim period between releases, monthly snapshots are built automatically by the FreeBSD Project build machines and made available for download from ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/. The widespread availability of binary release snapshots, and the tendency of our user community to keep up with -STABLE development with Subversion and “`make` `buildworld`” [4] helps to keep FreeBSD-STABLE in a very reliable condition even before the quality assurance activities ramp up pending a major release.

Bug reports and feature requests are continuously submitted by users throughout the release cycle. Problems reports are entered into our GNATS database [5] through email, the send-pr(1) application, or via the web interface provided at http://www.FreeBSD.org/send-pr.html.

To service our most conservative users, individual release branches were introduced with FreeBSD 4.3. These release branches are created shortly before a final release is made. After the release goes out, only the most critical security fixes and additions are merged onto the release branch. In addition to source updates via Subversion, binary patchkits are available to keep systems on the RELENG_`X`_`Y` branches updated.

## 1.1 What this article describes

The following sections of this article describe:

Section 2

  The different phases of the release engineering process leading up to the actual system build.

Section 3

  The actual build process.

Section 5

  How the base release may be extended by third parties.

Section 6

  Some of the lessons learned through the release of FreeBSD 4.4.

Section 7

  Future directions of development.

### Notes

[1] | Subversion, http://subversion.apache.org
[2] | FreeBSD committers
[3] | FreeBSD Core Team
[4] | Rebuilding "world"
[5] | GNATS: The GNU Bug Tracking System http://www.gnu.org/software/gnats

|  | Next
|  | Release Process