6. Release from stable/

This section describes the general procedures of the FreeBSD release cycle from an extablished stable/ branch.

6.1. FreeBSD stable Branch Code Slush

In preparation for the code freeze on a stable branch, several files need to be updated to reflect the release cycle is officially in progress. These files are all relative to the top-most level of the stable branch:

File to EditWhat to Change
sys/conf/newvers.shUpdate the BRANCH value to reflect PRERELEASE
Makefile.inc1Update TARGET_TRIPLE
lib/clang/llvm.build.mkUpdate OS_VERSION
Makefile.libcompatUpdate LIB32CPUFLAGS
gnu/usr.bin/groff/tmac/mdoc.local.inAdd a new .ds entry for the FreeBSD version, and update doc-default-operating-system (FreeBSD 11.x and earlier only)

In the doc repository, also update head/en_US.ISO8859-1/htdocs/releases/12.0R/Makefile.hardware, switching the value of _BRANCH to BETAX, RCX, or RELEASE, respectively.

6.2. FreeBSD BETA Builds

Following the code slush, the next phase of the release cycle is the code freeze. This is the point at which all commits to the stable branch require explicit approval from the FreeBSD Release Engineering Team. This is enforced by pre-commit hooks in the Subversion repository by editing base/svnadmin/conf/approvers to include a regular expression matching the stable/12/ branch for the release:

^/stable/12/	re
^/releng/12.0/	re


There are two general exceptions to requiring commit approval during the release cycle. The first is any change that needs to be committed by the Release Engineer in order to proceed with the day-to-day workflow of the release cycle, the other is security fixes that may occur during the release cycle.

Once the code freeze is in effect, the next build from the branch is labeled BETA1. This is done by updating the BRANCH value in sys/conf/newvers.sh from PRERELEASE to BETA1.

Once this is done, the first set of BETA builds are started. Subsequent BETA builds do not require updates to any files other than sys/conf/newvers.sh, incrementing the BETA build number.

6.3. Creating the releng/12.0/ Branch

When the first RC (Release Candidate) build is ready to begin, the releng/ branch is created. This is a multi-step process that must be done in a specific order, in order to avoid anomalies such as overlaps with __FreeBSD_version values, for example. The paths listed below are relative to the repository root. The order of commits and what to change are:

% svn cp ^/stable/12/ releng/12.0/
File to EditWhat to Change
releng/12.0/sys/conf/newvers.shChange BETAX to RC1
releng/12.0/sys/sys/param.hUpdate __FreeBSD_version
releng/12.0/etc/pkg/FreeBSD.confReplace latest with quarterly as the default package repository location
releng/12.0/release/pkg_repos/release-dvd.confReplace latest with quarterly as the default package repository location
stable/12/sys/conf/newvers.shUpdate BETAX with PRERELEASE
stable/12/sys/sys/param.hUpdate __FreeBSD_version
svnadmin/conf/approversAdd a new approvers line for the releng branch as was done for the stable branch
% svn propdel -R svn:mergeinfo releng/12.0/
% svn commit releng/12.0/
% svn commit stable/12/

Now that two new __FreeBSD_version values exist, also update head/en_US.ISO8859-1/books/porters-handbook/versions/chapter.xml in the Documentation Project repository.

After the first RC build has completed and tested, the stable/ branch can be thawed by removing (or commenting) the ^/stable/12/ entry in svnadmin/conf/approvers.

Following the availability of the first RC, FreeBSD Bugmeister Team should be emailed to add the new FreeBSD -RELEASE to the versions available in the drop-down menu shown in the bug tracker.

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.