2.Â Release Process

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.

2.1.Â Code Review

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 preceeding 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.

2.2.Â Final Release Checklist

When several BETA images have been made available for
widespread testing and all major issues have been resolved, the
final release “polishing” can begin.

2.2.1.Â Creating the Release Branch

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/X sources
that you want to branch from.

Note:

2.2.2.Â Bumping up the Version Number

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.xml

doc/en_US.ISO8859-1/books/porters-handbook/book.xml

doc/en_US.ISO8859-1/htdocs/cgi/ports.cgi

ports/Tools/scripts/release/config

doc/share/xml/freebsd.ent

src/Makefile.inc1

src/UPDATING

src/gnu/usr.bin/groff/tmac/mdoc.local

src/release/Makefile

src/release/doc/en_US.ISO8859-1/share/xml/release.dsl

src/release/doc/share/examples/Makefile.relnotesng

src/release/doc/share/xml/release.ent

src/sys/conf/newvers.sh

src/sys/sys/param.h

src/usr.sbin/pkg_install/add/main.c

doc/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.xml

src/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/sysinstall/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.pic

head/share/xml/release.ent

en_US.ISO8859-1/htdocs/releases/*

en_US.ISO8859-1/htdocs/releng/index.xml

share/xml/news.xml

Additionally, update the “BSD Family Tree”
file:

src/share/misc/bsd-family-tree

2.2.3.Â Creating the Release Tag

When the final release is ready, the following command
will create the release/9.2.0
tag.

#svn cp $FSVN/releng/9.2 $FSVN/release/9.2.0

The Documentation and Ports managers are responsible for
tagging their respective trees with the tags/RELEASE_9_2_0
tag.

When the Subversion svn cp command
is used to create a release tag,
this identifies the source at a specific point in time.
By creating tags, we ensure that future release builders
will always be able to use the exact same source we used to create the
official FreeBSD Project releases.