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 . The kinds of changes that are allowed during this 15 day period include:

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.

A “tag” is CVS vernacular for a label that identifies the source at a specific point in time. By tagging the tree, we ensure that future release builders will always be able to use the same source we used to create the official FreeBSD Project releases.

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/man.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[4]. This information is currently kept in src/usr.sbin/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 Preparing a new major release branch (RELENG_X)

When a new major release branch, such as RELENG_6 is branched from HEAD, some additional files must be updated before releases can be made from this new branch.

  • src/share/examples/cvsup/stable-supfile - must be updated to point to the new -STABLE branch, when applicable.

2.2.4 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 is not 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 reproducible. Local hacks in the release engineer's environment are not acceptable.

Prev Home Next
  Release Building

This, and other documents, can be downloaded from ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

For questions about FreeBSD, read the documentation before contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.