6. Release from stable/

6. Release from `stable/`
Prev		Next

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 Edit	What to Change
`sys/conf/newvers.sh`	Update the `BRANCH` value to reflect `PRERELEASE`
`Makefile.inc1`	Update `TARGET_TRIPLE`
`lib/clang/llvm.build.mk`	Update `OS_VERSION`
`Makefile.libcompat`	Update `LIB32CPUFLAGS`
`gnu/usr.bin/groff/tmac/mdoc.local.in`	Add 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

Note:

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 Edit	What to Change
`releng/12.0/sys/conf/newvers.sh`	Change `BETAX` to `RC1`
`releng/12.0/sys/sys/param.h`	Update `__FreeBSD_version`
`releng/12.0/etc/pkg/FreeBSD.conf`	Replace `latest` with `quarterly` as the default package repository location
`releng/12.0/release/pkg_repos/release-dvd.conf`	Replace `latest` with `quarterly` as the default package repository location
`stable/12/sys/conf/newvers.sh`	Update `BETAX` with `PRERELEASE`
`stable/12/sys/sys/param.h`	Update `__FreeBSD_version`
`svnadmin/conf/approvers`	Add 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.

Prev		Next
5. Release from `head/`	Home	7. Building FreeBSD Installation Media