Date: Tue, 12 Jun 2018 18:07:07 +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: r51822 - head/en_US.ISO8859-1/articles/releng Message-ID: <201806121807.w5CI77jE040120@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: bcr Date: Tue Jun 12 18:07:07 2018 New Revision: 51822 URL: https://svnweb.freebsd.org/changeset/doc/51822 Log: Make igor happier about the releng article source. In particular, a lot of spaces were replaced by tabs, indentations were corrected, two spaces after a setence stop were added, and titles where capitalized when needed. I've kept the "redundant markup and words" and contraction errors as they were, in order not to change the historical text and the original author's words. 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 07:13:14 2018 (r51821) +++ head/en_US.ISO8859-1/articles/releng/article.xml Tue Jun 12 18:07:07 2018 (r51822) @@ -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"> @@ -35,395 +46,402 @@ <pubdate>$FreeBSD$</pubdate> <abstract> - <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> + <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> - </info> + <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 +449,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 +549,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> - *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201806121807.w5CI77jE040120>