The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: sect1/para
Context English State
After a reasonable testing period, changes can then be merged to the <literal>stable/</literal> branches. The default minimum timeframe before merging to <literal>stable/</literal> branches is three (3) days.
Although a general rule to wait a minimum of three days before merging from <literal>head/</literal>, 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 <literal>stable/</literal> branch have grown significantly, it is time to release the next version of FreeBSD. These releases have been historically referred to as <quote>point</quote> releases.
In between releases from the <literal>stable/</literal> branches, approximately every two (2) years, a release will be cut directly from <literal>head/</literal>. These releases have been historically referred to as <quote>dot-zero</quote> releases.
This article will highlight the workflow and responsibilities of the FreeBSD Release Engineering Team for both <quote>dot-zero</quote> and <quote>point</quote>' 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 <quote>code slush</quote> and <quote>code freeze</quote>, used throughout this document.
The Release Engineering process for a <quote>dot-zero</quote> release.
The Release Engineering process for a <quote>point</quote> release.
Information related to the specific procedures to build installation medium.
Procedures to publish installation medium.
Wrapping up the release cycle.
General Information and Preparation
Approximately two months before the start of the release cycle, the FreeBSD Release Engineering Team 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
<literal>head/</literal> slush:
May 27, 2016
<literal>head/</literal> freeze:
June 10, 2016
<literal>head/</literal> KBI freeze:
June 24, 2016
<literal>doc/</literal> tree slush [1]:
Ports quarterly branch [2]:
July 1, 2016
<literal>stable/<replaceable>12</replaceable>/</literal> branch:
July 8, 2016
<literal>doc/</literal> tree tag [3]:
BETA1 build starts:

Loading…

No matching activity found.

Browse all component changes

Source information

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