Date: Tue, 12 Jun 2018 18:54:46 +0000 (UTC) From: Benedict Reuschling <bcr@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r51824 - head/en_US.ISO8859-1/articles/releng Message-ID: <201806121854.w5CIskU2065851@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
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@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@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@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@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 ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201806121854.w5CIskU2065851>