English Italian (it_IT)
FreeBSD Release Engineering
This article describes the release engineering process of the FreeBSD Project.
Introduction to the FreeBSD Release Engineering Process
Development of FreeBSD has a very specific workflow. In general, all changes to the FreeBSD base system are committed to the {branchHead} branch, which reflects the top of the source tree.
After a reasonable testing period, changes can then be merged to the {branchStable} branches. The default minimum timeframe before merging to {branchStable} branches is three (3) days.
Although a general rule to wait a minimum of three days before merging from {branchHead}, there are a few special circumstances where an immediate merge may be necessary, such as a critical security fix, or a bug fix that directly inhibits the release build process.
After several months, and the number of changes in the {branchStable} branch have grown significantly, it is time to release the next version of FreeBSD. These releases have been historically referred to as "point" releases.
In between releases from the {branchStable} branches, approximately every two (2) years, a release will be cut directly from {branchHead}. These releases have been historically referred to as "dot-zero" releases.
This article will highlight the workflow and responsibilities of the {teamRe} for both "dot-zero" and "point"' releases.
The following sections of this article describe:
General information and preparation before starting the release cycle.
Website Changes During the Release Cycle
Terminology and general information, such as the "code slush" and "code freeze", used throughout this document.
The Release Engineering process for a "dot-zero" release.