&os; Release Engineering

+ + &os; Release Engineering + + + &tm-attrib.freebsd; + &tm-attrib.intel; + &tm-attrib.general; + + + $FreeBSD$ + + + This article describes the release engineering process of + the &os; Project. + + + + + Introduction to the &os; Release Engineering + Process + + Development of &os; has a very specific workflow. In + general, all changes to the &os; base system are committed to + the head/ branch, which reflects the top of + the source tree. + + After a reasonable testing period, changes can then be + merged to the stable/ branches. The default + minimum timeframe before merging to stable/ + branches is three (3) days. + + Although a general rule to wait a minimum of three days + before mergeing from head/, 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 + stable/ branch have grown significantly, it + is time to release the next version of &os;. These releases + have been historically referred to as point + releases. + + In between releases from the stable/ + branches, approximately every two (2) years, a release will be + cut directly from head/. These releases + have been historically referred to as dot-zero + releases. + + This article will highlight the workflow and + responsibilities of the &team.re; for both + dot-zero and point' + releases. + + The following sections of this article describe: + + + + + + + General information and preparation before + starting the release cycle. + + + + + + + + The Release Engineering process for a + dot-zero release. + + + + + + + + The Release Engineering process for a + point release. + + + + + + + General Information and Preparation + + Approximately two months before the start of the release + cycle, the &team.re; decides on a schedule for the release. + The schedule includes the various milestone points of the + release cycle, such as freeze dates, branch dates, and build + dates. For example: + + + + + + Milestone + Anticipated Date + + + + + + head/ slush: + August 24 + + + + head/ freeze: + September 7 + + + + head/ KBI freeze: + September 21 + + + + stable/10/ + branch: + October 10 + + + + BETA1 build starts: + October 12 + + + + BETA2 build starts: + October 18 + + + + releng/10.0/ + branch: + November 1 + + + + RC1 build starts: + November 1 + + + + RC2 build starts: + November 9 + + + + RELEASE build starts: + November 19 + + + + + + After general agreement on the schedule, the &team.re; + emails the the schedule to the &os; Developers. + + + + Release from <literal>head/</literal> + + + + + + + Release from <literal>stable/</literal> + + + + +