Source string Read only

(itstool) path: listitem/para
33/330
Context English State
A set of more stable branches are maintained, known as <quote>FreeBSD-STABLE</quote> or <quote>-STABLE</quote> for short. All branches live in a master Subversion repository maintained by the FreeBSD Project. FreeBSD-CURRENT is the <quote>bleeding-edge</quote> of FreeBSD development where all new changes first enter the system. FreeBSD-STABLE is the development branch from which major releases are made. Changes go into this branch at a different pace, and with the general assumption that they have first gone into FreeBSD-CURRENT and have been thoroughly tested by our user community.
The term <emphasis>stable</emphasis> in the name of the branch refers to the presumed Application Binary Interface stability, which is promised by the project. This means that a user application compiled on an older version of the system from the same branch works on a newer system from the same branch. The ABI stability has improved greatly from the compared to previous releases. In most cases, binaries from the older <emphasis>STABLE</emphasis> systems run unmodified on newer systems, including <emphasis>HEAD</emphasis>, assuming that the system management interfaces are not used.
buildworld
<link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/makeworld.html">Rebuilding "world"</link>
In the interim period between releases, weekly snapshots are built automatically by the FreeBSD Project build machines and made available for download from <systemitem>ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/</systemitem>. The widespread availability of binary release snapshots, and the tendency of our user community to keep up with -STABLE development with Subversion and <quote><command>make</command> <_:buildtarget-1/></quote> <_:footnote-2/> helps to keep FreeBSD-STABLE in a very reliable condition even before the quality assurance activities ramp up pending a major release.
In addition to installation ISO snapshots, weekly virtual machine images are also provided for use with <application>VirtualBox</application>, <application>qemu</application>, or other popular emulation software. The virtual machine images can be downloaded from <systemitem>ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/VM-IMAGES/</systemitem>.
The virtual machine images are approximately 150MB <citerefentry><refentrytitle>xz</refentrytitle><manvolnum>1</manvolnum></citerefentry> compressed, and contain a 10GB sparse filesystem when attached to a virtual machine.
Bug reports and feature requests are continuously submitted by users throughout the release cycle. Problems reports are entered into our <application>Bugzilla</application> database through the web interface provided at <uri xlink:href="https://www.freebsd.org/support/bugreports.html">https://www.freebsd.org/support/bugreports.html</uri>.
To service our most conservative users, individual release branches were introduced with FreeBSD 4.3. These release branches are created shortly before a final release is made. After the release goes out, only the most critical security fixes and additions are merged onto the release branch. In addition to source updates via Subversion, binary patchkits are available to keep systems on the <emphasis>releng/<replaceable>X</replaceable>.<replaceable>Y</replaceable></emphasis> branches updated.
What This Article Describes
The following sections of this article describe:
The different phases of the release engineering process leading up to the actual system build.
The actual build process.
How the base release may be extended by third parties.
Some of the lessons learned through the release of FreeBSD 4.4.
Future directions of development.
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 <quote>MFC sweeps</quote>.
<acronym>MFC</acronym> stands for <quote>Merge From CURRENT</quote> 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.
Code Review
Sixty days before the anticipated release, the source repository enters a <quote>code freeze</quote>. During this time, all commits to the -STABLE branch must be approved by Release Engineering Team <email>re@FreeBSD.org</email>. 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 <emphasis>BETA1</emphasis> 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 <emphasis>Release Candidate</emphasis> (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 <quote>hard code freeze</quote> where it becomes much harder to justify new changes to the system unless a serious bug-fix or security issue is involved.
Final Release Checklist
When several BETA images have been made available for widespread testing and all major issues have been resolved, the final release <quote>polishing</quote> can begin.

Loading…

No matching activity found.

Browse all component changes

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: listitem/para
Flags
read-only
Source string location
article.translate.xml:226
String age
a year ago
Source string age
a year ago
Translation file
articles/releng.pot, string 35