2. General Information and Preparation

2. General Information and Preparation
Prev		Next

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
`head/` slush:	May 27, 2016
`head/` freeze:	June 10, 2016
`head/` KBI freeze:	June 24, 2016
`doc/` tree slush [1]:	June 24, 2016
Ports quarterly branch [2]:	July 1, 2016
`stable/12/` branch:	July 8, 2016
`doc/` tree tag [3]:	July 8, 2016
BETA1 build starts:	July 8, 2016
`head/` thaw:	July 9, 2016
BETA2 build starts:	July 15, 2016
BETA3 build starts [*]:	July 22, 2016
`releng/12.0/` branch:	July 29, 2016
RC1 build starts:	July 29, 2016
`stable/12/` thaw:	July 30, 2016
RC2 build starts:	August 5, 2016
Final Ports package builds [4]:	August 6, 2016
Ports release tag:	August 12, 2016
RC3 build starts [*]:	August 12, 2016
RELEASE build starts:	August 19, 2016
RELEASE announcement:	September 2, 2016

Note:

Items marked with "[*]" are "as needed".

The doc/ tree slush is coordinated by the FreeBSD Documentation Engineering Team.
The Ports quarterly branch used is determined by when the final RC build is planned. A new quarterly branch is created on the first day of the quarter, so this metric should be used when taking the release cycle milestones into account. The quarterly branch is created by the FreeBSD Ports Management Team.
The doc/ tree is tagged by the FreeBSD Documentation Engineering Team.
The final Ports package build is done by the FreeBSD Ports Management Team after the final (or what is expected to be final) RC build.

Note:

If the release is being created from an existing stable/ branch, the KBI freeze date can be excluded, since the KBI is already considered frozen on established stable/ branches.

When writing the release cycle schedule, a number of things need to be taken into consideration, in particular milestones where the target date depends on predefined milestones upon which there is a dependency. For example, the Ports Collection release tag originates from the active quarterly branch at the time of the last RC. This in part defines which quarterly branch is used, when the release tag can happen, and what revision of the ports tree is used for the final RELEASE build.

After general agreement on the schedule, the FreeBSD Release Engineering Team emails the schedule to the FreeBSD Developers.

It is somewhat typical that many developers will inform the FreeBSD Release Engineering Team about various works-in-progress. In some cases, an extension for the in-progress work will be requested, and in other cases, a request for “blanket approval” to a particular subset of the tree will be made.

When such requests are made, it is important to make sure timelines (even if estimated) are discussed. For blanket approvals, the length of time for the blanket approval should be made clear. For example, a FreeBSD developer may request blanket approvals from the start of the code slush until the start of the RC builds.

Note:

In order to keep track of blanket approvals, the FreeBSD Release Engineering Team uses an internal repository to keep a running log of such requests, which defines the area upon which a blanket approval was granted, the author(s), when the blanket approval expires, and the reason the approval was granted. One example of this is granting blanket approval to release/doc/ to all FreeBSD Release Engineering Team members until the final RC to update the release notes and other release-related documentation.

Note:

The FreeBSD Release Engineering Team also uses this repository to track pending approval requests that are received just prior to starting various builds during the release cycle, which the Release Engineer specifies the cutoff period with an email to the FreeBSD developers.

Depending on the underlying set of code in question, and the overall impact the set of code has on FreeBSD as a whole, such requests may be approved or denied by the FreeBSD Release Engineering Team.

The same applies to work-in-progress extensions. For example, in-progress work for a new device driver that is otherwise isolated from the rest of the tree may be granted an extension. A new scheduler, however, may not be feasible, especially if such dramatic changes do not exist in another branch.

The schedule is also added to the Project website, in the doc/ repository, in head/en_US.ISO8859-1/htdocs/releases/12.0R/schedule.xml. This file is continuously updated as the release cycle progresses.

Note:

In most cases, the schedule.xml can be copied from a prior release and updated accordingly.

In addition to adding schedule.xml to the website, head/share/xml/navibar.ent and head/share/xml/release.ent are also updated to add the link to the schedule to various subpages, as well as enabling the link to the schedule on the Project website index page.

The schedule is also linked from head/en_US.ISO8859-1/htdocs/releng/index.xml.

Approximately one month prior to the scheduled “code slush”, the FreeBSD Release Engineering Team sends a reminder email to the FreeBSD Developers.

Once the first builds of the release cycle are available, update the beta.local.where entity in head/en_US.ISO8859-1/htdocs/releases/12.0R/schedule.xml. replacing IGNORE with INCLUDE.

Note:

If two parallel release cycles are happening at once, the beta2.local.where entity may be used instead.

Prev		Next
FreeBSD Release Engineering	Home	3. Release Engineering Terminology