New releases of FreeBSD are released from the -STABLE branch at approximately four month intervals. The FreeBSD release process begins to ramp up 70-80 days before the anticipated release date when the release engineer sends an email to the development mailing lists to remind developers that they only have 15 days to integrate new changes before the code freeze. During this time, many developers perform what have become known as “MFC sweeps”.
MFC stands for “Merge From CURRENT” and it describes the process of merging a tested change from our -CURRENT development branch to our -STABLE branch. Project policy requires any change to be first applied to trunk, and merged to the -STABLE branches after sufficient external testing was done by -CURRENT users (developers are expected to extensively test the change before committing to -CURRENT, but it is impossible for a person to exercise all usages of the general-purpose operating system). Minimal MFC period is 3 days, which is typically used only for trivial or critical bugfixes.
Sixty days before the anticipated release, the source
repository enters a “code freeze”. During this
time, all commits to the -STABLE branch must be approved by
Release Engineering Team <re@FreeBSD.org>. The approval process is technically enforced by a
pre-commit hook. The kinds of changes that are allowed
during this period include:
Bug fixes.
Documentation updates.
Security-related fixes of any kind.
Minor changes to device drivers, such as adding new Device IDs.
Driver updates from the vendors.
Any additional change that the release engineering team feels is justified, given the potential risk.
Shortly after the code freeze is started, a BETA1 image is built and released for widespread testing. During the code freeze, at least one beta image or release candidate is released every two weeks until the final release is ready. During the days preceding the final release, the release engineering team is in constant communication with the security-officer team, the documentation maintainers, and the port maintainers to ensure that all of the different components required for a successful release are available.
After the quality of the BETA images is satisfying enough, and no large and potentially risky changes are planned, the release branch is created and Release Candidate (RC) images are built from the release branch, instead of the BETA images from the STABLE branch. Also, the freeze on the STABLE branch is lifted and release branch enters a “hard code freeze” where it becomes much harder to justify new changes to the system unless a serious bug-fix or security issue is involved.
When several BETA images have been made available for widespread testing and all major issues have been resolved, the final release “polishing” can begin.
Note:
In all examples below,
$FSVN refers to the location
of the FreeBSD Subversion repository,
svn+ssh://svn.FreeBSD.org/base/.
The layout of FreeBSD branches in Subversion is described
in the Committer's
Guide. The first step in creating a branch is to
identify the revision of the
stable/
sources that you want to branch
from.X
#svn log -v $FSVN/stable/9
The next step is to create the release branch
#svn cp $FSVN/stable/9@REVISION $FSVN/releng/9.2
This branch can be checked out:
#svn co $FSVN/releng/9.2 src
Note:
Creating the releng branch and
release tags is done by the Release
Engineering Team.
Before the final release can be tagged, built, and released, the following files need to be modified to reflect the correct version of FreeBSD:
doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xmldoc/en_US.ISO8859-1/books/porters-handbook/book.xmldoc/en_US.ISO8859-1/htdocs/cgi/ports.cgiports/Tools/scripts/release/configdoc/share/xml/freebsd.entsrc/Makefile.inc1src/UPDATINGsrc/gnu/usr.bin/groff/tmac/mdoc.localsrc/release/Makefilesrc/release/doc/en_US.ISO8859-1/share/xml/release.dslsrc/release/doc/share/examples/Makefile.relnotesngsrc/release/doc/share/xml/release.entsrc/sys/conf/newvers.shsrc/sys/sys/param.hsrc/usr.sbin/pkg_install/add/main.cdoc/en_US.ISO8859-1/htdocs/search/opensearch/man.xml
The release notes and errata files also need to be adjusted for the new release (on the release branch) and truncated appropriately (on the stable/current branch):
src/release/doc/en_US.ISO8859-1/relnotes/common/new.xmlsrc/release/doc/en_US.ISO8859-1/errata/article.xml
Sysinstall should be updated to
note the number of available ports and the amount of disk
space required for the Ports Collection.
[5]
This information is currently kept in
src/usr.sbin/bsdinstall/dist.c.
After the release has been built, a number of files should
be updated to announce the release to the world. These files
are relative to head/ within the
doc/ subversion tree.
share/images/articles/releng/branches-relengX.pichead/share/xml/release.enten_US.ISO8859-1/htdocs/releases/*en_US.ISO8859-1/htdocs/releng/index.xmlshare/xml/news.xml
Additionally, update the “BSD Family Tree” file:
src/share/misc/bsd-family-tree