FreeBSD Release Engineering

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 to the main repository 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 usually the people who do the bulk of FreeBSD development. An elected Core Team ^[3] of developers provide some level of direction over the project.

The rapid pace of FreeBSD development makes the main development branch unsuitable for the everyday use by the general public. In particular, stabilizing efforts are required for polishing the development system into a production quality release. To solve this conflict, development continues on several parallel tracks. The main development branch is the HEAD or trunk of our Subversion tree, known as “FreeBSD-CURRENT” or “-CURRENT” for short.

A set of more stable branches are maintained, known as “FreeBSD-STABLE” or “-STABLE” for short. All branches live in a master Subversion repository 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.

The term stable in the name of the branch refers to the presumed Application Binary Interface stability, which is promised by the project. This means that a user application compiled on an older version of the system from the same branch works on a newer system from the same branch. The ABI stability has improved greatly from the compared to previous releases. In most cases, binaries from the older STABLE systems run unmodified on newer systems, including HEAD, assuming that the system management interfaces are not used.

In the interim period between releases, weekly 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.

In addition to installation ISO snapshots, weekly virtual machine images are also provided for use with VirtualBox, qemu, or other popular emulation software. The virtual machine images can be downloaded from ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/VM-IMAGES/.

The virtual machine images are approximately 150MB xz(1) compressed, and contain a 10GB sparse filesystem when attached to a virtual machine.

Bug reports and feature requests are continuously submitted by users throughout the release cycle. Problems reports are entered into our Bugzilla database through the web interface provided at https://www.freebsd.org/support/bugreports.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.