Release from &branch.stable;
This section describes the general procedures of the &os;
release cycle from an extablished &branch.stable; branch.
&os; 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 LILB32CPUFLAGS
gnu/usr.bin/groff/tmac/mdoc.local.in
Add a new .ds entry for the &os;
version, and update
doc-default-operating-system
(&os; 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.
&os; 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 &team.re;. This is enforced by pre-commit hooks in the
Subversion repository by editing
base/svnadmin/conf/approvers to include
a regular expression matching the &branch.stablex; branch for
the release:
^/&branch.stablex; re
^/&branch.relengx; 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.
Creating the &branch.relengx; Branch
When the first RC (Release Candidate)
build is ready to begin, the &branch.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:
&prompt.user; svn cp ^/&branch.stablex; &branch.relengx;
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
&prompt.user; svn propdel -R svn:mergeinfo &branch.relengx;
&prompt.user; svn commit &branch.relengx;
&prompt.user; svn commit &branch.stablex;
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 &branch.stable; branch can be
thawed
by removing (or commenting) the
^/&branch.stablex; entry in
svnadmin/conf/approvers.
Following the availability of the first
RC, &team.bugmeister; should be emailed to
add the new &os; -RELEASE to the
versions available in the drop-down menu
shown in the bug tracker.