Date: Tue, 12 Jun 2018 18:19:12 +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: r51823 - head/en_US.ISO8859-1/articles/releng Message-ID: <201806121819.w5CIJCBB045679@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
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@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"> @@ -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@REVISION $FSVN/releng/9.2</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> - <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 ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201806121819.w5CIJCBB045679>