FreeBSD Release Engineering
Prev		Next

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

2.1 Code Review

Thirty days before the anticipated release, the source repository enters a “code slush”. During this time, all commits to the -STABLE branch must be approved by the Release Engineering Team <re@FreeBSD.org>. The kinds of changes that are allowed during this 15 day period include:

Bug fixes.
Documentation updates.
Security-related fixes of any kind.
Minor changes to device drivers, such as adding new Device IDs.
Any additional change that the release engineering team feels is justified, given the potential risk.

After the first 15 days of the code slush, a release candidate is released for widespread testing and the code enters a “code freeze” where it becomes much harder to justify new changes to the system unless a serious bug-fix or security issue is involved. During the code freeze, at least one release candidate is released per week, until the final release is ready. During the days leading to 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.

2.2 Final Release Checklist

When several release candidates 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

As described in the introduction, the RELENG_X_Y release branch is a relatively new addition to our release engineering methodology. The first step in creating this branch is to ensure that you are working with the newest version of the RELENG_X sources that you want to branch from.

/usr/src# cvs update -rRELENG_4 -P -d

The next step is to create a branch point tag, so that diffs against the start of the branch are easier with CVS:

/usr/src# cvs rtag -rRELENG_4 RELENG_4_8_BP src

And then a new branch tag is created with:

/usr/src# cvs rtag -b -rRELENG_4_8_BP RELENG_4_8 src

Note: The RELENG_* tags are restricted for use by the CVS-meisters and release engineers.

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.sgml
doc/en_US.ISO8859-1/books/porters-handbook/book.sgml
doc/share/sgml/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/sgml/release.dsl
src/release/doc/share/examples/Makefile.relnotesng
src/release/doc/share/sgml/release.ent
src/share/examples/cvsup/standard-supfile
src/sys/conf/newvers.sh
src/sys/sys/param.h
src/usr.sbin/pkg_install/add/main.c
www/en/docs.sgml
www/en/cgi/ports.cgi
ports/Tools/scripts/release/config

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.sgml
src/release/doc/en_US.ISO8859-1/errata/article.sgml

Sysinstall should be updated to note the number of available ports and the amount of disk space required for the Ports Collection. This information is currently kept in src/release/sysinstall/dist.c.

After the release has been built, a number of file should be updated to announce the release to the world.

doc/share/images/articles/releng/branches-relengX.pic
www/share/sgml/advisories.xml
www/share/sgml/includes.release.sgml
www/share/sgml/includes.release.xsl
www/en/releases/*
www/en/releng/index.sgml
www/en/news/news.xml
www/en/search/web.atoz
src/share/misc/bsd-family-tree

2.2.3 Creating Release Tags

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

/usr/src# cvs rtag -rRELENG_4_8 RELENG_4_8_0_RELEASE src

The Documentation and Ports managers are responsible for tagging the respective trees with the RELEASE_4_8_0 tag.

Occasionally, a last minute fix may be required after the final tags have been created. In practice this isn't a problem, since CVS allows tags to be manipulated with cvs tag -d tagname filename. It is very important that any last minute changes be tagged appropriately as part of the release. FreeBSD releases must always be reproduceable. Local hacks in the release engineer's environment are not acceptable.