Index: head/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml =================================================================== --- head/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml (revision 50337) +++ head/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml (revision 50338) @@ -1,180 +1,174 @@ Release from &branch.stable; This section describes the general procedures of the &os; release cycle from an extablished &branch.stable; branch. &os; <literal>stable</literal> Branch Code Slush In preparation for the code freeze on a stable branch, several files need to be updated to reflect the release cycle is officially in progress. These files are all relative to the top-most level of the stable branch: File to Edit What to Change gnu/usr.bin/groff/tmac/mdoc.local.in Add the new &os; version sys/conf/newvers.sh Update the BRANCH value to reflect PRERELEASE Makefile.inc1 Update TARGET_TRIPLE - - - lib/clang/freebsd_cc_version.h - Update - FREEBSD_CC_VERSION - &os; <literal>BETA</literal> Builds Following the code slush, the next phase of the release cycle is the code freeze. This is the point at which all commits to the stable branch require explicit approval from the &team.re;. This is enforced by pre-commit hooks in the Subversion repository by editing base/svnadmin/conf/approvers to include a regular expression matching the &branch.stablex; branch for the release: ^/&branch.stablex; re There are two general exceptions to requiring commit approval during the release cycle. The first is any change that needs to be committed by the Release Engineer in order to proceed with the day-to-day workflow of the release cycle, the other is security fixes that may occur during the release cycle. Once the code freeze is in effect, the next build from the branch is labeled BETA1. This is done by updating the BRANCH value in sys/conf/newvers.sh from PRERELEASE to BETA1. Once this is done, the first set of BETA builds are started. Subsequent BETA builds do not require updates to any files other than sys/conf/newvers.sh, incrementing the BETA build number. Creating the &branch.relengx; Branch When the first RC (Release Candidate) build is ready to begin, the &branch.releng; branch is created. This is a multi-step process that must be done in a specific order, in order to avoid anomalies such as overlaps with __FreeBSD_version values, for example. The paths listed below are relative to the repository root. The order of commits and what to change are: &prompt.user; svn cp ^/&branch.stablex; &branch.relengx; File to Edit What to Change releng/11.0/sys/conf/newvers.sh Change BETAX to RC1 releng/11.0/sys/sys/param.h Update __FreeBSD_version releng/11.0/etc/pkg/FreeBSD.conf Replace latest with quarterly as the default package repository location releng/11.0/release/pkg_repos/release-dvd.conf Replace latest with quarterly as the default package repository location stable/11/sys/conf/newver.sh Update BETAX with PRERELEASE stable/11/sys/sys/param.h Update __FreeBSD_version svnadmin/conf/approvers Add a new approvers line for the releng branch as was done for the stable branch &prompt.user; svn propdel -R svn:mergeinfo &branch.relengx; &prompt.user; svn commit &branch.relengx; &prompt.user; svn commit &branch.stablex; Now that two new __FreeBSD_version values exist, also update head/en_US.ISO8859-1/books/porters-handbook/versions/chapter.xml in the Documentation Project repository. After the first RC build has completed and tested, the &branch.stable; branch can be thawed by removing (or commenting) the ^/&branch.stablex; entry in svnadmin/conf/approvers.