svn commit: r51824 - head/en_US.ISO8859-1/articles/releng
Benedict Reuschling
bcr at FreeBSD.org
Tue Jun 12 18:54:47 UTC 2018
Author: bcr
Date: Tue Jun 12 18:54:46 2018
New Revision: 51824
URL: https://svnweb.freebsd.org/changeset/doc/51824
Log:
Re-commit my cleanup changes.
Apparently, igor does not like the occurance of the second <para> in the
<para><note><para> sequence in the abstract. Replacing it with something else
makes the file not pass the DTD checks. Err on the side of letting the file
compile, leaving a couple of igor checks unresolved.
Overall, the docbook xml source in this file should be much cleaner now.
Modified:
head/en_US.ISO8859-1/articles/releng/article.xml
Modified: head/en_US.ISO8859-1/articles/releng/article.xml
==============================================================================
--- head/en_US.ISO8859-1/articles/releng/article.xml Tue Jun 12 18:19:12 2018 (r51823)
+++ head/en_US.ISO8859-1/articles/releng/article.xml Tue Jun 12 18:54:46 2018 (r51824)
@@ -2,28 +2,39 @@
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN"
"http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd" [
]>
-<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
-
- <info><title>&os; Release Engineering</title>
+<article xmlns="http://docbook.org/ns/docbook"
+ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
+ xml:lang="en">
-
-
+ <info>
+ <title>&os; Release Engineering</title>
+
<confgroup>
<confdates>November 2001</confdates>
<conftitle>BSDCon Europe</conftitle>
</confgroup>
<authorgroup>
- <author><personname><firstname>Murray</firstname><surname>Stokely</surname></personname><personblurb>
- <para>I've been involved in the development of &os; based products
- since 1997 at Walnut Creek CDROM, BSDi, and now Wind River Systems.
- &os; 4.4 was the first official release of &os; that I played
- a significant part in.</para>
- </personblurb><affiliation>
- <address><email>murray at FreeBSD.org</email>
- <otheraddr xlink:href="https://people.FreeBSD.org/~murray/">https://people.FreeBSD.org/~murray/</otheraddr>
- </address>
- </affiliation></author>
+ <author>
+ <personname>
+ <firstname>Murray</firstname>
+ <surname>Stokely</surname>
+ </personname>
+ <personblurb>
+ <para>I've been involved in the development of &os; based
+ products since 1997 at Walnut Creek CDROM, BSDi, and now
+ Wind River Systems. &os; 4.4 was the first official
+ release of &os; that I played a significant part
+ in.</para>
+ </personblurb>
+ <affiliation>
+ <address>
+ <email>murray at FreeBSD.org</email>
+ <otheraddr
+ xlink:href="https://people.FreeBSD.org/~murray/">https://people.FreeBSD.org/~murray/</otheraddr>
+ </address>
+ </affiliation>
+ </author>
</authorgroup>
<legalnotice xml:id="trademarks" role="trademarks">
@@ -36,394 +47,402 @@
<abstract>
<para>
- <note>
+ <note>
<para>This document is outdated and does not accurately
describe the current release procedures of the &os;
Release Engineering team. It is retained for historical
purposes. The current procedures used by the &os; Release
Engineering team are available in the <link
xlink:href="&url.articles.freebsd-releng;/article.html">&os;
- Release Engineering</link> article.</para>
- </note>
- </para>
- <para>This paper describes the approach used by the &os;
- release engineering team to make production quality releases
- of the &os; Operating System. It details the methodology
- used for the official &os; releases and describes the tools
- available for those interested in producing customized &os;
- releases for corporate rollouts or commercial
- productization.</para>
- </abstract>
+ Release Engineering</link> article.</para></note></para>
+ <para>This paper describes the approach used by the &os;
+ release engineering team to make production quality
+ releases of the &os; Operating System. It details the
+ methodology used for the official &os; releases and
+ describes the tools available for those interested in
+ producing customized &os; releases for corporate rollouts
+ or commercial productization.</para>
+ </abstract>
</info>
<!-- Introduction -->
-<sect1 xml:id="introduction">
- <title>Introduction</title>
+ <sect1 xml:id="introduction">
+ <title>Introduction</title>
- <para>The development of &os; is a very open process. &os; is
- comprised of contributions from thousands of people around the
- world. The &os; Project provides
- Subversion
- <footnote>
- <simpara>
- Subversion, <uri xlink:href="http://subversion.apache.org">http://subversion.apache.org</uri>
- </simpara>
- </footnote>
- access to the general public so that
- others can have access to log messages, diffs (patches) between
- development branches, and other productivity enhancements that
- formal source code management provides. This has been a huge help
- in attracting more talented developers to &os;. However, I
- think everyone would agree that chaos would soon manifest if write
- access to the main repository was opened up to everyone on the Internet.
- Therefore only a <quote>select</quote> group of nearly 300 people are
- given write access to the Subversion repository. These
- <link xlink:href="&url.articles.contributors;/article.html#staff-committers">committers</link>
- <footnote>
- <simpara>
- <link xlink:href="&url.articles.contributors;/article.html#staff-committers">FreeBSD committers</link>
- </simpara>
- </footnote>
- are usually the people who do the bulk of &os; development. An elected
- <link xlink:href="&url.base;/administration.html#t-core">Core Team</link>
- <footnote>
- <simpara>
- <link xlink:href="&url.base;/administration.html#t-core">&os; Core Team</link>
- </simpara>
- </footnote>
- of developers provide some level of direction over the project.</para>
+ <para>The development of &os; is a very open process. &os; is
+ comprised of contributions from thousands of people around the
+ world. The &os; Project provides Subversion <footnote>
+ <simpara>Subversion, <uri
+ xlink:href="http://subversion.apache.org">http://subversion.apache.org</uri>
+ </simpara></footnote> access to the general public so that
+ others can have access to log messages, diffs (patches)
+ between development branches, and other productivity
+ enhancements that formal source code management provides.
+ This has been a huge help in attracting more talented
+ developers to &os;. However, I think everyone would agree
+ that chaos would soon manifest if write access to the main
+ repository was opened up to everyone on the Internet.
+ Therefore only a <quote>select</quote> group of nearly 300
+ people are given write access to the Subversion repository.
+ These <link
+ xlink:href="&url.articles.contributors;/article.html#staff-committers">committers</link>
+ <footnote>
+ <simpara><link
+ xlink:href="&url.articles.contributors;/article.html#staff-committers">FreeBSD
+ committers</link>
+ </simpara>
+ </footnote>
+ are usually the people who do the bulk of &os; development.
+ An elected <link
+ xlink:href="&url.base;/administration.html#t-core">Core
+ Team</link>
+ <footnote>
+ <simpara><link
+ xlink:href="&url.base;/administration.html#t-core">&os;
+ Core Team</link></simpara>
+ </footnote>
+ of developers provide some level of direction over the
+ project.</para>
- <para>The rapid pace of <systemitem>&os;</systemitem>
- development makes the main development branch unsuitable for the
- everyday use by the general public. In particular, stabilizing
- efforts are required for polishing the development system into a
- production quality release. To solve this conflict, development
- continues on several parallel tracks. The main development branch
- is the <emphasis>HEAD</emphasis> or <emphasis>trunk</emphasis> of
- our Subversion tree, known as <quote>&os;-CURRENT</quote> or
- <quote>-CURRENT</quote> for short.</para>
+ <para>The rapid pace of <systemitem>&os;</systemitem>
+ development makes the main development branch unsuitable for
+ the everyday use by the general public. In particular,
+ stabilizing efforts are required for polishing the development
+ system into a production quality release. To solve this
+ conflict, development continues on several parallel tracks.
+ The main development branch is the <emphasis>HEAD</emphasis>
+ or <emphasis>trunk</emphasis> of our Subversion tree, known as
+ <quote>&os;-CURRENT</quote> or <quote>-CURRENT</quote> for
+ short.</para>
- <para>A set of more stable branches are maintained, known as
- <quote>&os;-STABLE</quote> or <quote>-STABLE</quote> for short.
- All branches live in a master Subversion repository maintained by the
- &os; Project. &os;-CURRENT is the <quote>bleeding-edge</quote> of
- &os; development where all new changes first enter the system.
- &os;-STABLE is the development branch from which major releases
- are made. Changes go into this branch at a different pace, and
- with the general assumption that they have first gone into
- &os;-CURRENT and have been thoroughly tested by our user
- community.</para>
+ <para>A set of more stable branches are maintained, known as
+ <quote>&os;-STABLE</quote> or <quote>-STABLE</quote> for
+ short. All branches live in a master Subversion repository
+ maintained by the &os; Project. &os;-CURRENT is the
+ <quote>bleeding-edge</quote> of &os; development where all new
+ changes first enter the system. &os;-STABLE is the
+ development branch from which major releases are made.
+ Changes go into this branch at a different pace, and with the
+ general assumption that they have first gone into &os;-CURRENT
+ and have been thoroughly tested by our user community.</para>
- <para>The term <emphasis>stable</emphasis> in the name of the branch
- refers to the presumed Application Binary Interface stability,
- which is promised by the project. This means that a user
- application compiled on an older version of the system from the
- same branch works on a newer system from the same branch. The
- ABI stability has improved greatly from the compared to previous
- releases. In most cases, binaries from the older
- <emphasis>STABLE</emphasis> systems run unmodified on newer systems,
- including <emphasis>HEAD</emphasis>, assuming that the system
- management interfaces are not used.</para>
+ <para>The term <emphasis>stable</emphasis> in the name of the
+ branch refers to the presumed Application Binary Interface
+ stability, which is promised by the project. This means that
+ a user application compiled on an older version of the system
+ from the same branch works on a newer system from the same
+ branch. The ABI stability has improved greatly from the
+ compared to previous releases. In most cases, binaries from
+ the older <emphasis>STABLE</emphasis> systems run unmodified
+ on newer systems, including <emphasis>HEAD</emphasis>,
+ assuming that the system management interfaces are not
+ used.</para>
- <para>In the interim period between releases, weekly snapshots are
- built automatically by the &os; Project build machines and made
- available for download from <systemitem>ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/</systemitem>.
- The widespread availability of binary release snapshots, and the
- tendency of our user community to keep up with -STABLE development
- with Subversion and <quote><command>make</command>
- <buildtarget>buildworld</buildtarget></quote>
- <footnote>
- <simpara>
- <link xlink:href="&url.books.handbook;/makeworld.html">Rebuilding "world"</link>
- </simpara>
- </footnote>
- helps to keep
- &os;-STABLE in a very reliable condition even before the
- quality assurance activities ramp up pending a major
- release.</para>
+ <para>In the interim period between releases, weekly snapshots
+ are built automatically by the &os; Project build machines and
+ made available for download from
+ <systemitem>ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/</systemitem>.
+ The widespread availability of binary release snapshots, and
+ the tendency of our user community to keep up with -STABLE
+ development with Subversion and <quote><command>make</command>
+ <buildtarget>buildworld</buildtarget></quote> <footnote>
+ <simpara><link
+ xlink:href="&url.books.handbook;/makeworld.html">Rebuilding
+ "world"</link></simpara></footnote> helps to keep
+ &os;-STABLE in a very reliable condition even before the
+ quality assurance activities ramp up pending a major
+ release.</para>
- <para>In addition to installation ISO snapshots, weekly virtual
- machine images are also provided for use with
- <application>VirtualBox</application>,
- <application>qemu</application>, or other popular emulation
- software. The virtual machine images can be downloaded from
- <systemitem>ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/VM-IMAGES/</systemitem>.</para>
+ <para>In addition to installation ISO snapshots, weekly virtual
+ machine images are also provided for use with
+ <application>VirtualBox</application>,
+ <application>qemu</application>, or other popular emulation
+ software. The virtual machine images can be downloaded from
+ <systemitem>ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/VM-IMAGES/</systemitem>.</para>
- <para>The virtual machine images are approximately 150MB &man.xz.1;
- compressed, and contain a 10GB sparse filesystem when attached to
- a virtual machine.</para>
+ <para>The virtual machine images are approximately 150MB
+ &man.xz.1; compressed, and contain a 10GB sparse filesystem
+ when attached to a virtual machine.</para>
- <para>Bug reports and feature requests are continuously submitted by
- users throughout the release cycle. Problems reports are entered into our
- <application>Bugzilla</application> database
- through the web
- interface provided at <uri xlink:href="https://www.freebsd.org/support/bugreports.html">https://www.freebsd.org/support/bugreports.html</uri>.</para>
-
- <para>To service our most conservative users, individual release
- branches were introduced with &os; 4.3.
- These release branches are created shortly before a final release
- is made. After the release goes out, only the most critical
- security fixes and additions are merged onto the release branch.
- In addition to source updates via Subversion, binary patchkits are
- available to keep systems on the
- <emphasis>releng/<replaceable>X</replaceable>.<replaceable>Y</replaceable></emphasis>
- branches updated.</para>
-
- <sect2>
- <title>What this article describes</title>
-
- <para>The following sections of this article describe:</para>
-
- <variablelist>
- <varlistentry>
- <term><xref linkend="release-proc"/></term>
-
- <listitem>
- <para>The different phases of the release engineering process
- leading up to the actual system build.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><xref linkend="release-build"/></term>
-
- <listitem>
- <para>The actual build process.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><xref linkend="extensibility"/></term>
+ <para>Bug reports and feature requests are continuously
+ submitted by users throughout the release cycle. Problems
+ reports are entered into our
+ <application>Bugzilla</application> database through the web
+ interface provided at <uri
+ xlink:href="https://www.freebsd.org/support/bugreports.html">https://www.freebsd.org/support/bugreports.html</uri>.</para>
- <listitem>
- <para>How the base release may be extended by third parties.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><xref linkend="lessons-learned"/></term>
+ <para>To service our most conservative users, individual release
+ branches were introduced with &os; 4.3. These release
+ branches are created shortly before a final release is made.
+ After the release goes out, only the most critical security
+ fixes and additions are merged onto the release branch. In
+ addition to source updates via Subversion, binary patchkits
+ are available to keep systems on the
+ <emphasis>releng/<replaceable>X</replaceable>.<replaceable>Y</replaceable></emphasis>
+ branches updated.</para>
- <listitem>
- <para>Some of the lessons learned through the release of &os; 4.4.</para>
- </listitem>
- </varlistentry>
+ <sect2>
+ <title>What This Article Describes</title>
- <varlistentry>
- <term><xref linkend="future"/></term>
+ <para>The following sections of this article describe:</para>
- <listitem>
- <para>Future directions of development.</para>
- </listitem>
- </varlistentry>
- </variablelist>
- </sect2>
-</sect1>
+ <variablelist>
+ <varlistentry>
+ <term><xref linkend="release-proc"/></term>
+ <listitem>
+ <para>The different phases of the release engineering
+ process leading up to the actual system build.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><xref linkend="release-build"/></term>
+
+ <listitem>
+ <para>The actual build process.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><xref linkend="extensibility"/></term>
+
+ <listitem>
+ <para>How the base release may be extended by third
+ parties.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><xref linkend="lessons-learned"/></term>
+
+ <listitem>
+ <para>Some of the lessons learned through the release of
+ &os; 4.4.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><xref linkend="future"/></term>
+
+ <listitem>
+ <para>Future directions of development.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </sect2>
+ </sect1>
+
<!-- Release Process -->
-<sect1 xml:id="release-proc">
- <title>Release Process</title>
+ <sect1 xml:id="release-proc">
+ <title>Release Process</title>
- <para>New releases of &os; are released from the -STABLE branch
- at approximately four month intervals. The &os; release
- process begins to ramp up 70-80 days before the anticipated release
- date when the release engineer sends an email to the development
- mailing lists to remind developers that they only have 15 days to
- integrate new changes before the code freeze. During this time,
- many developers perform what have become known as <quote>MFC
- sweeps</quote>.</para>
+ <para>New releases of &os; are released from the -STABLE branch
+ at approximately four month intervals. The &os; release
+ process begins to ramp up 70-80 days before the anticipated
+ release date when the release engineer sends an email to the
+ development mailing lists to remind developers that they only
+ have 15 days to integrate new changes before the code freeze.
+ During this time, many developers perform what have become
+ known as <quote>MFC sweeps</quote>.</para>
- <para><acronym>MFC</acronym> stands for <quote>Merge From
- CURRENT</quote> and it describes the process of merging a tested
- change from our -CURRENT development branch to our -STABLE branch.
- Project policy requires any change to be first applied to
- trunk, and merged to the -STABLE branches after sufficient
- external testing was done by -CURRENT users (developers are
- expected to extensively test the change before committing to
- -CURRENT, but it is impossible for a person to exercise all usages
- of the general-purpose operating system). Minimal MFC period is 3
- days, which is typically used only for trivial or critical
- bugfixes.</para>
+ <para><acronym>MFC</acronym> stands for <quote>Merge From
+ CURRENT</quote> and it describes the process of merging a
+ tested change from our -CURRENT development branch to our
+ -STABLE branch. Project policy requires any change to be
+ first applied to trunk, and merged to the -STABLE branches
+ after sufficient external testing was done by -CURRENT users
+ (developers are expected to extensively test the change before
+ committing to -CURRENT, but it is impossible for a person to
+ exercise all usages of the general-purpose operating system).
+ Minimal MFC period is 3 days, which is typically used only for
+ trivial or critical bugfixes.</para>
- <sect2>
- <title>Code Review</title>
+ <sect2>
+ <title>Code Review</title>
- <para>Sixty days before the anticipated release, the source
- repository enters a <quote>code freeze</quote>. During this
- time, all commits to the -STABLE branch must be approved by
- &a.re;. The approval process is technically enforced by a
- pre-commit hook. The kinds of changes that are allowed during
- this period include:</para>
+ <para>Sixty days before the anticipated release, the source
+ repository enters a <quote>code freeze</quote>. During this
+ time, all commits to the -STABLE branch must be approved by
+ &a.re;. The approval process is technically enforced by a
+ pre-commit hook. The kinds of changes that are allowed
+ during this period include:</para>
- <itemizedlist>
- <listitem>
- <para>Bug fixes.</para>
- </listitem>
+ <itemizedlist>
+ <listitem>
+ <para>Bug fixes.</para>
+ </listitem>
- <listitem>
- <para>Documentation updates.</para>
- </listitem>
+ <listitem>
+ <para>Documentation updates.</para>
+ </listitem>
- <listitem>
- <para>Security-related fixes of any kind.</para>
- </listitem>
+ <listitem>
+ <para>Security-related fixes of any kind.</para>
+ </listitem>
- <listitem>
- <para>Minor changes to device drivers, such as adding new Device
- IDs.</para>
- </listitem>
+ <listitem>
+ <para>Minor changes to device drivers, such as adding new
+ Device IDs.</para>
+ </listitem>
- <listitem>
- <para>Driver updates from the vendors.</para>
- </listitem>
+ <listitem>
+ <para>Driver updates from the vendors.</para>
+ </listitem>
- <listitem>
- <para>Any additional change that the release engineering team feels
- is justified, given the potential risk.</para>
- </listitem>
- </itemizedlist>
+ <listitem>
+ <para>Any additional change that the release engineering
+ team feels is justified, given the potential
+ risk.</para>
+ </listitem>
+ </itemizedlist>
- <para>Shortly after the code freeze is started, a
- <emphasis>BETA1</emphasis> image is built and released for
- widespread testing. During the code freeze, at least one beta
- image or release candidate is released every two weeks until the
- final release is ready. During the days preceeding the final
- release, the release engineering team is in constant
- communication with the security-officer team, the documentation
- maintainers, and the port maintainers to ensure that all of the
- different components required for a successful release are
- available.</para>
+ <para>Shortly after the code freeze is started, a
+ <emphasis>BETA1</emphasis> image is built and released for
+ widespread testing. During the code freeze, at least one
+ beta image or release candidate is released every two weeks
+ until the final release is ready. During the days preceding
+ the final release, the release engineering team is in
+ constant communication with the security-officer team, the
+ documentation maintainers, and the port maintainers to
+ ensure that all of the different components required for a
+ successful release are available.</para>
- <para>After the quality of the BETA images is satisfying enough,
- and no large and potentially risky changes are planned, the
- release branch is created and <emphasis>Release
- Candidate</emphasis> (RC) images are built from the release
- branch, instead of the BETA images from the STABLE branch.
- Also, the freeze on the STABLE branch is lifted and release
- branch enters a <quote>hard code freeze</quote> where it becomes
- much harder to justify new changes to the system unless a
- serious bug-fix or security issue is involved.</para>
- </sect2>
+ <para>After the quality of the BETA images is satisfying
+ enough, and no large and potentially risky changes are
+ planned, the release branch is created and <emphasis>Release
+ Candidate</emphasis> (RC) images are built from the
+ release branch, instead of the BETA images from the STABLE
+ branch. Also, the freeze on the STABLE branch is lifted and
+ release branch enters a <quote>hard code freeze</quote>
+ where it becomes much harder to justify new changes to the
+ system unless a serious bug-fix or security issue is
+ involved.</para>
+ </sect2>
- <sect2>
- <title>Final Release Checklist</title>
+ <sect2>
+ <title>Final Release Checklist</title>
- <para>When several BETA images have been made available for
- widespread testing and all major issues have been resolved, the
- final release <quote>polishing</quote> can begin.</para>
+ <para>When several BETA images have been made available for
+ widespread testing and all major issues have been resolved,
+ the final release <quote>polishing</quote> can begin.</para>
- <sect3 xml:id="rel-branch">
- <title>Creating the Release Branch</title>
+ <sect3 xml:id="rel-branch">
+ <title>Creating the Release Branch</title>
- <note>
- <para>In all examples below, <literal>$FSVN</literal>
- refers to the location of the &os; Subversion repository,
- <literal>svn+ssh://svn.FreeBSD.org/base/</literal>.</para>
- </note>
+ <note>
+ <para>In all examples below,
+ <literal>$FSVN</literal> refers to the location
+ of the &os; Subversion repository,
+ <literal>svn+ssh://svn.FreeBSD.org/base/</literal>.</para>
+ </note>
- <para>The layout of &os; branches in Subversion is
- described in the <link xlink:href="&url.articles.committers-guide;/subversion-primer.html#subversion-primer-base-layout">Committer's Guide</link>.
- The first step in creating a branch is to
- identify the revision of the
- <literal>stable/<replaceable>X</replaceable></literal> sources
- that you want to branch <emphasis>from</emphasis>.</para>
+ <para>The layout of &os; branches in Subversion is described
+ in the <link
+ xlink:href="&url.articles.committers-guide;/subversion-primer.html#subversion-primer-base-layout">Committer's
+ Guide</link>. The first step in creating a branch is to
+ identify the revision of the
+ <literal>stable/<replaceable>X</replaceable></literal>
+ sources that you want to branch
+ <emphasis>from</emphasis>.</para>
- <screen>&prompt.root; <userinput>svn log -v $FSVN/stable/9</userinput></screen>
+ <screen>&prompt.root; <userinput>svn log -v $FSVN/stable/9</userinput></screen>
- <para>The next step is to create the <emphasis>release branch</emphasis>
- </para>
-
- <screen>&prompt.root; <userinput>svn cp $FSVN/stable/9 at REVISION $FSVN/releng/9.2</userinput></screen>
+ <para>The next step is to create the <emphasis>release
+ branch</emphasis></para>
- <para>This branch can be checked out:</para>
-
- <screen>&prompt.root; <userinput>svn co $FSVN/releng/9.2 src</userinput></screen>
+ <screen>&prompt.root; <userinput>svn cp $FSVN/stable/9 at REVISION $FSVN/releng/9.2</userinput></screen>
+ <para>This branch can be checked out:</para>
+
+ <screen>&prompt.root; <userinput>svn co $FSVN/releng/9.2 src</userinput></screen>
+
<note>
- <para>Creating the <literal>releng</literal> branch and
- <literal>release</literal> tags is done by the <link xlink:href="&url.base;/administration.html#t-re">Release
- Engineering Team</link>.
- </para>
+ <para>Creating the <literal>releng</literal> branch and
+ <literal>release</literal> tags is done by the <link
+ xlink:href="&url.base;/administration.html#t-re">Release
+ Engineering Team</link>.</para>
</note>
<mediaobject>
- <imageobject>
- <imagedata fileref="branches-head" align="center"/>
- </imageobject>
+ <imageobject>
+ <imagedata fileref="branches-head" align="center"/>
+ </imageobject>
- <textobject>
- <phrase>&os; Development Branch</phrase>
- </textobject>
+ <textobject>
+ <phrase>&os; Development Branch</phrase>
+ </textobject>
</mediaobject>
<mediaobject>
- <imageobject>
- <imagedata fileref="branches-releng3" align="center"/>
- </imageobject>
+ <imageobject>
+ <imagedata fileref="branches-releng3" align="center"/>
+ </imageobject>
- <textobject>
- <phrase>&os; 3.x STABLE Branch</phrase>
- </textobject>
+ <textobject>
+ <phrase>&os; 3.x STABLE Branch</phrase>
+ </textobject>
</mediaobject>
<mediaobject>
- <imageobject>
- <imagedata fileref="branches-releng4" align="center"/>
- </imageobject>
+ <imageobject>
+ <imagedata fileref="branches-releng4" align="center"/>
+ </imageobject>
- <textobject>
- <phrase>&os; 4.x STABLE Branch</phrase>
- </textobject>
+ <textobject>
+ <phrase>&os; 4.x STABLE Branch</phrase>
+ </textobject>
</mediaobject>
<mediaobject>
- <imageobject>
- <imagedata fileref="branches-releng5" align="center"/>
- </imageobject>
+ <imageobject>
+ <imagedata fileref="branches-releng5" align="center"/>
+ </imageobject>
- <textobject>
- <phrase>&os; 5.x STABLE Branch</phrase>
- </textobject>
+ <textobject>
+ <phrase>&os; 5.x STABLE Branch</phrase>
+ </textobject>
</mediaobject>
<mediaobject>
- <imageobject>
- <imagedata fileref="branches-releng6" align="center"/>
- </imageobject>
+ <imageobject>
+ <imagedata fileref="branches-releng6" align="center"/>
+ </imageobject>
- <textobject>
- <phrase>&os; 6.x STABLE Branch</phrase>
- </textobject>
+ <textobject>
+ <phrase>&os; 6.x STABLE Branch</phrase>
+ </textobject>
</mediaobject>
<mediaobject>
- <imageobject>
- <imagedata fileref="branches-releng7" align="center"/>
- </imageobject>
+ <imageobject>
+ <imagedata fileref="branches-releng7" align="center"/>
+ </imageobject>
- <textobject>
- <phrase>&os; 7.x STABLE Branch</phrase>
- </textobject>
+ <textobject>
+ <phrase>&os; 7.x STABLE Branch</phrase>
+ </textobject>
</mediaobject>
<mediaobject>
- <imageobject>
- <imagedata fileref="branches-releng8" align="center"/>
- </imageobject>
+ <imageobject>
+ <imagedata fileref="branches-releng8" align="center"/>
+ </imageobject>
- <textobject>
- <phrase>&os; 8.x STABLE Branch</phrase>
- </textobject>
+ <textobject>
+ <phrase>&os; 8.x STABLE Branch</phrase>
+ </textobject>
</mediaobject>
<mediaobject>
- <imageobject>
- <imagedata fileref="branches-releng9" align="center"/>
- </imageobject>
+ <imageobject>
+ <imagedata fileref="branches-releng9" align="center"/>
+ </imageobject>
- <textobject>
- <phrase>&os; 9.x STABLE Branch</phrase>
- </textobject>
+ <textobject>
+ <phrase>&os; 9.x STABLE Branch</phrase>
+ </textobject>
</mediaobject>
</sect3>
@@ -431,104 +450,98 @@
<title>Bumping up the Version Number</title>
<para>Before the final release can be tagged, built, and
- released, the following files need to be modified to reflect
- the correct version of &os;:</para>
+ released, the following files need to be modified to reflect
+ the correct version of &os;:</para>
<itemizedlist>
- <listitem>
- <para><filename>doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml
- </filename></para>
- </listitem>
+ <listitem>
+ <para><filename>doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml</filename></para>
+ </listitem>
- <listitem>
- <para><filename>doc/en_US.ISO8859-1/books/porters-handbook/book.xml
- </filename></para>
- </listitem>
+ <listitem>
+ <para><filename>doc/en_US.ISO8859-1/books/porters-handbook/book.xml</filename></para>
+ </listitem>
- <listitem>
- <para><filename>doc/en_US.ISO8859-1/htdocs/cgi/ports.cgi</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>doc/en_US.ISO8859-1/htdocs/cgi/ports.cgi</filename></para>
+ </listitem>
- <listitem>
- <para><filename>ports/Tools/scripts/release/config</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>ports/Tools/scripts/release/config</filename></para>
+ </listitem>
+ <listitem>
+ <para><filename>doc/share/xml/freebsd.ent</filename></para>
+ </listitem>
- <listitem>
- <para><filename>doc/share/xml/freebsd.ent</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/Makefile.inc1</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/Makefile.inc1</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/UPDATING</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/UPDATING</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/gnu/usr.bin/groff/tmac/mdoc.local</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/gnu/usr.bin/groff/tmac/mdoc.local</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/release/Makefile</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/release/Makefile</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/release/doc/en_US.ISO8859-1/share/xml/release.dsl</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/release/doc/en_US.ISO8859-1/share/xml/release.dsl</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/release/doc/share/examples/Makefile.relnotesng</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/release/doc/share/examples/Makefile.relnotesng</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/release/doc/share/xml/release.ent</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/release/doc/share/xml/release.ent</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/sys/conf/newvers.sh</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/sys/conf/newvers.sh</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/sys/sys/param.h</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/sys/sys/param.h</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/usr.sbin/pkg_install/add/main.c</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/usr.sbin/pkg_install/add/main.c</filename></para>
- </listitem>
-
- <listitem>
- <para><filename>doc/en_US.ISO8859-1/htdocs/search/opensearch/man.xml</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>doc/en_US.ISO8859-1/htdocs/search/opensearch/man.xml</filename></para>
+ </listitem>
</itemizedlist>
- <para>The release notes and errata files also need to be adjusted for the
- new release (on the release branch) and truncated appropriately
- (on the stable/current branch):</para>
+ <para>The release notes and errata files also need to be
+ adjusted for the new release (on the release branch) and
+ truncated appropriately (on the stable/current branch):</para>
<itemizedlist>
- <listitem>
- <para><filename>src/release/doc/en_US.ISO8859-1/relnotes/common/new.xml
- </filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/release/doc/en_US.ISO8859-1/relnotes/common/new.xml</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/release/doc/en_US.ISO8859-1/errata/article.xml
- </filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/release/doc/en_US.ISO8859-1/errata/article.xml</filename></para>
+ </listitem>
</itemizedlist>
- <para><application>Sysinstall</application> should be updated to note
- the number of available ports and the amount of disk space required
- for the Ports Collection.
- <footnote>
- <simpara>
- &os; Ports Collection
- <uri xlink:href="https://www.FreeBSD.org/ports">https://www.FreeBSD.org/ports</uri>
- </simpara>
- </footnote>
- This information is currently kept in
+ <para><application>Sysinstall</application> should be updated to
+ note the number of available ports and the amount of disk
+ space required for the Ports Collection.
+ <footnote>
+ <simpara>&os; Ports Collection <uri
+ xlink:href="https://www.FreeBSD.org/ports">https://www.FreeBSD.org/ports</uri>
+ </simpara>
+ </footnote>
+ This information is currently kept in
<filename>src/usr.sbin/bsdinstall/dist.c</filename>.</para>
<para>After the release has been built, a number of files should
@@ -537,62 +550,57 @@
<literal>doc/</literal> subversion tree.</para>
<itemizedlist>
- <listitem>
- <para><filename>share/images/articles/releng/branches-releng<replaceable>X</replaceable>.pic</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>share/images/articles/releng/branches-releng<replaceable>X</replaceable>.pic</filename></para>
+ </listitem>
- <listitem>
+ <listitem>
<para><filename>head/share/xml/release.ent</filename></para>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para><filename>en_US.ISO8859-1/htdocs/releases/*</filename></para>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para><filename>en_US.ISO8859-1/htdocs/releng/index.xml</filename></para>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para><filename>share/xml/news.xml</filename></para>
- </listitem>
+ </listitem>
</itemizedlist>
<para>Additionally, update the <quote>BSD Family Tree</quote>
file:</para>
<itemizedlist>
- <listitem>
- <para><filename>src/share/misc/bsd-family-tree</filename></para>
- </listitem>
-
+ <listitem>
+ <para><filename>src/share/misc/bsd-family-tree</filename></para>
+ </listitem>
</itemizedlist>
-
</sect3>
<sect3>
<title>Creating the Release Tag</title>
<para>When the final release is ready, the following command
- will create the <literal>release/9.2.0</literal>
- tag.</para>
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
More information about the svn-doc-all
mailing list