Index: user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml
===================================================================
--- user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml (revision 50063)
+++ user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml (revision 50064)
@@ -1,75 +1,202 @@
Release from &branch.head;
This section describes the general procedures of the &os;
release cycle from the &branch.head; branch.
&os; <quote><literal>ALPHA</literal></quote> Builds
Starting with the &os; 10.0-RELEASE cycle, the notion
of ALPHA
builds was
introduced. Unlike the BETA and
RC builds, ALPHA builds
are not included in the &os; Release schedule.
The idea behind ALPHA builds is to
provide regular &os;-provided builds before the creation of the
&branch.stable; branch.
&os; ALPHA snapshots should be built
approximately once a week.
For the first ALPHA build, the
BRANCH value in
sys/conf/newvers.sh needs to be changed
from CURRENT to ALPHA1.
For subsequent ALPHA builds, increment each
ALPHAN value by
one.
See for information on
building the ALPHA images.
Creating the &branch.stablex; Branch
When creating the &branch.stable; branch, several changes
are required in both the new &branch.stable; branch and the
- &branch.head; branch.
+ &branch.head; branch. The files listed are relative to the
+ repository root. To create the new &branch.stablex; branch
+ in Subversion:
- &prompt.user; svn cp head &branch.stablex;
+
+ Once the &branch.stablex; branch has been committed, make
+ the following edits:
+
File to Edit
What to Change
-
-
+ stable/11/UPDATING
+ Update the &os; version, and remove the notice
+ about WITNESS
+
+
+ stable/11/contrib/jemalloc/include/jemalloc/jemalloc_FreeBSD.h
+ #ifndef MALLOC_PRODUCTION
+#define MALLOC_PRODUCTION
+#endif
+
+
+
+ stable/11/sys/*/conf/GENERIC*
+ Remove debugging support
+
+
+
+ stable/11/release/release.conf.sample
+ Update SRCBRANCH
+
+
+
+ stable/11/sys/*/conf/GENERIC-NODEBUG
+ Remove these kernel configurations
+
+
+
+ stable/11/sys/conf/newvers.sh
+ Update the BRANCH value to
+ reflect PRERELEASE
+
- ?>
+
+ Then in the &branch.head; branch, which will now become
+ a new major version:
+
+
+
+
+
+ File to Edit
+ What to Change
+
+
+
+
+
+ head/UPDATING
+ Update the &os; version
+
+
+
+ head/gnu/usr.bin/groff/tmac/mdoc.local.in
+ Add the new &os; version
+
+
+
+ head/sys/conf/newvers.sh
+ Update the BRANCH value to
+ reflect CURRENT, and increment
+ REVISION
+
+
+
+ head/Makefile.inc1
+ Update TARGET_TRIPLE
+
+
+
+ head/sys/sys/param.h
+ Update __FreeBSD_version
+
+
+
+ head/contrib/llvm/tools/clang/lib/Basic/Targets.cpp
+ Update
+ __FreeBSD_cc_version
+
+
+
+ head/gnu/usr.bin/cc/cc_tools/freebsd-native.h
+ Update FBSD_MAJOR and
+ FBSD_CC_VER
+
+
+
+ head/contrib/gcc/config.gcc
+ Append the
+ freebsd<version>.h
+ section
+
+
+
+ head/release/Makefile
+ Remove the
+ debug.witness.trace entries
+
+
+
+ head/release/doc/en_US.ISO8859-1/readme/article.xml
+ Replace &a.current; with &a.stable;
+
+
+
+ head/release/doc/share/xml/release.ent
+
+
+
+ ?>
+
+
+ head/lib/clang/clang.build.mk
+ Uncomment -DNDEBUG
+
+
+
+ head/lib/clang/freebsd_cc_version.h
+ Update
+ FREEBSD_CC_VERSION
+
+
+
+
Code Thaw in &branch.head;
Index: user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml
===================================================================
--- user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml (revision 50063)
+++ user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml (revision 50064)
@@ -1,36 +1,178 @@
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
+
+
+
+
+
+
&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:
-
- Code Thaw in the &branch.stablex; Branch
+ &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 upate
+ 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.
&os; <literal>RC</literal> Builds