svn commit: r51823 - head/en_US.ISO8859-1/articles/releng
Benedict Reuschling
bcr at FreeBSD.org
Tue Jun 12 18:19:13 UTC 2018
Author: bcr
Date: Tue Jun 12 18:19:12 2018
New Revision: 51823
URL: https://svnweb.freebsd.org/changeset/doc/51823
Log:
Revert until I figure out the build breakage.
Yes, I should have tested it locally first.
Pointy hat to: me
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:07:07 2018 (r51822)
+++ head/en_US.ISO8859-1/articles/releng/article.xml Tue Jun 12 18:19:12 2018 (r51823)
@@ -2,39 +2,28 @@
<!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">
+<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>
- <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">
@@ -46,402 +35,395 @@
<pubdate>$FreeBSD$</pubdate>
<abstract>
- <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>
+ <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>
- <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>
+ </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>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>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>How the base release may be extended by third parties.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><xref linkend="lessons-learned"/></term>
- <sect2>
- <title>What This Article Describes</title>
+ <listitem>
+ <para>Some of the lessons learned through the release of &os; 4.4.</para>
+ </listitem>
+ </varlistentry>
- <para>The following sections of this article describe:</para>
+ <varlistentry>
+ <term><xref linkend="future"/></term>
- <variablelist>
- <varlistentry>
- <term><xref linkend="release-proc"/></term>
+ <listitem>
+ <para>Future directions of development.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </sect2>
+</sect1>
- <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 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>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>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>
+ <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>
- <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>
- <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>
@@ -449,98 +431,104 @@
<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>src/Makefile.inc1</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>doc/share/xml/freebsd.ent</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/UPDATING</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/Makefile.inc1</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/gnu/usr.bin/groff/tmac/mdoc.local</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/UPDATING</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/release/Makefile</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/gnu/usr.bin/groff/tmac/mdoc.local</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/Makefile</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/release/doc/share/examples/Makefile.relnotesng</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/xml/release.ent</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/release/doc/share/examples/Makefile.relnotesng</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/sys/conf/newvers.sh</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/release/doc/share/xml/release.ent</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/sys/sys/param.h</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/sys/conf/newvers.sh</filename></para>
+ </listitem>
- <listitem>
- <para><filename>src/usr.sbin/pkg_install/add/main.c</filename></para>
- </listitem>
+ <listitem>
+ <para><filename>src/sys/sys/param.h</filename></para>
+ </listitem>
- <listitem>
- <para><filename>doc/en_US.ISO8859-1/htdocs/search/opensearch/man.xml</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>
</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
@@ -549,57 +537,62 @@
<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>
+
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
More information about the svn-doc-all
mailing list