LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

Work in progress

This commit is contained in:
vivekv 2001-12-13 17:31:49 +00:00
parent b3a097b898
commit 0fb7262485
1 changed files with 272 additions and 104 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

376
LDP/ref/docbook/CVS-BestPractices/CVS-BestPractices.sgml
View File

@ -1,7 +1,7 @@
<!DOCTYPE ARTICLE PUBLIC "-//OASIS//DTD DocBook V4.1//EN" [
<!-- Document version -->
<!ENTITY DOCVERSION "0.3">
<!ENTITY DOCVERSION "0.4">
<!-- File Includes -->
<!ENTITY GFDL-FILE SYSTEM "gfdl.sgml">
@ -12,8 +12,40 @@
<!ENTITY CVSAB "CVS">
<!ENTITY SCMAB "SCM">
<!ENTITY SCM "Software configuration management">
<!ENTITY MYEMAIL "vivekv at yahoo.com">
<!ENTITY MYEMAIL "vivek at magic-cauldron.com">
<!-- All the best practices described in one place.... -->
<!ENTITY section2-useguiclient "Use GUI &CVSAB; client">
<!ENTITY section1-devsandbox "Developer Sandbox">
<!ENTITY section2-clockinsync "Keep System clocks in Sync">
<!ENTITY section2-dontshare "Do not share the sandbox">
<!ENTITY section2-syncup "Stay in sync with the repository">
<!ENTITY section2-workinside "Do not work outside the sandbox">
<!ENTITY section2-cleanupatcompletion "Cleanup after Completion">
<!ENTITY section2-checkin "Check-in Often">
<!ENTITY section1-serverconfig "&CVSAB; Server Configuration">
<!ENTITY section2-scripting "Server side scripting">
<!ENTITY section2-notification "Server Notification">
<!ENTITY section1-branchmerge "Branching and Merging">
<!ENTITY section2-branchowner "Assign ownership to Trunk and Branches">
<!ENTITY section2-tagrelease "Tag each release">
<!ENTITY section2-branchatrelease "Create a branch after each release">
<!ENTITY section2-bugfixbranches "Make bug fixes to branches only">
<!ENTITY section2-patchesfrombranches "Make patch releases from branches only">
<!ENTITY section1-chgpropagation "Change Propagation">
<!ENTITY section2-mergebugfix "Merge branch with the trunk after release">
<!ENTITY section1-softwarebuild "Software Builds">
<!ENTITY section2-bebo "Build Early and Build Often">
<!ENTITY section2-automate "Automate build Process completely">
<!ENTITY section2-ensurecheckin "All necessary files must be checked before build">
<!ENTITY section1-instprocess "Institutionalize &CVSAB; in the Organization">
<!ENTITY section2-chngmgmt "Implement Change Management Process">
<!ENTITY section2-objectives "Make &CVSAB; Usage part of Objectives">
<!ENTITY section2-metrics "Collect metrics on &CVSAB; usage">
]>
<article>
@ -30,6 +62,14 @@
<revhistory>
<revision>
<revnumber>0.4</revnumber>
<date></date>
<authorinitials>vv</authorinitials>
<revremark>Added new email address, Added an example flow to show how the
practices help</revremark>
</revision>
<revision>
<revnumber>0.3</revnumber>
<date>2001-12-06</date>
@ -41,7 +81,8 @@
<revnumber>0.2</revnumber>
<date>2001-11-27</date>
<authorinitials>vv</authorinitials>
<revremark>Incorporated first round of feedback and some minor fixes</revremark></revision>
<revremark>Incorporated first round of feedback and
some minor fixes</revremark></revision>
<revision>
<revnumber>0.1</revnumber>
@ -160,7 +201,7 @@ major installation and backups at regular intervals. </para> </sect2>
<orderedlist>
<listitem>
<para>
<ulink url="http://www.geocities.com/vivekv/cvs-bestpractices/index-cvs-bestpractices.html">My website</ulink>
<ulink url="http://www.magic-cauldron.com/cm/cvs-bestpractices/index-cvs-bestpractices.html">My website</ulink>
</para>
</listitem>
<listitem>
@ -207,11 +248,11 @@ additions, comments and criticisms to the following email address :
</para>
<orderedlist>
<listitem>
<para>GUI Tools
<para><xref linkend="section1-guitools">
</para>
<itemizedlist>
<listitem>
<para>Use GUI tools for &CVSAB; client
<para><xref linkend="section2-useguiclient">
</para>
</listitem>
</itemizedlist>
@ -219,31 +260,31 @@ additions, comments and criticisms to the following email address :
</listitem>
<listitem>
<para>Developer Sandbox
<para><xref linkend="section1-devsandbox">
</para>
<itemizedlist>
<listitem>
<para>Keep System clocks in Sync
<para><xref linkend="section2-clockinsync">
</para>
</listitem>
<listitem>
<para>Do not share the sandbox
<para><xref linkend="section2-dontshare">
</para>
</listitem>
<listitem>
<para>Stay in sync with the repository
<para><xref linkend="section2-syncup">
</para>
</listitem>
<listitem>
<para>Do not work outside the sandbox
<para><xref linkend="section2-workinside">
</para>
</listitem>
<listitem>
<para>Cleanup after completion
<para><xref linkend="section2-cleanupatcompletion">
</para>
</listitem>
<listitem>
<para>Check-in often
<para><xref linkend="section2-checkin">
</para>
</listitem>
</itemizedlist>
@ -251,16 +292,16 @@ additions, comments and criticisms to the following email address :
</listitem>
<listitem>
<para>Server Configuration
<para><xref linkend="section1-serverconfig">
</para>
<itemizedlist>
<listitem>
<para>&CVSAB; Server side scripting
<para><xref linkend="section2-scripting">
</para>
</listitem>
<listitem>
<para>&CVSAB; Server notification
<para><xref linkend="section2-notification">
</para>
</listitem>
@ -269,27 +310,27 @@ additions, comments and criticisms to the following email address :
<listitem>
<para>Branching and Merging
<para><xref linkend="section1-branchmerge">
</para>
<itemizedlist>
<listitem>
<para>Assign ownership to trunk and branches
<para><xref linkend="section2-branchowner">
</para>
</listitem>
<listitem>
<para>Tag each release
<para><xref linkend="section2-tagrelease">
</para>
</listitem>
<listitem>
<para>Create a branch after each release
<para><xref linkend="section2-branchatrelease">
</para>
</listitem>
<listitem>
<para>Make bug fixes to branches only
<para><xref linkend="section2-bugfixbranches">
</para>
</listitem>
<listitem>
<para>Make patch releases from branches only
<para><xref linkend="section2-patchesfrombranches">
</para>
</listitem>
@ -297,49 +338,49 @@ additions, comments and criticisms to the following email address :
</listitem>
<listitem>
<para>Change propagation
<para><xref linkend="section1-chgpropagation">
</para>
<itemizedlist>
<listitem>
<para>Merge branch with the trunk after each release
<para><xref linkend="section2-mergebugfix">
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>Software Builds
<para><xref linkend="section1-softwarebuild">
</para>
<itemizedlist>
<listitem>
<para>Build early and build often
<para><xref linkend="section2-bebo">
</para>
</listitem>
<listitem>
<para>Automate build process completely
<para><xref linkend="section2-automate">
</para>
</listitem>
<listitem>
<para>All necessary files must be checked in before a build
<para><xref linkend="section2-ensurecheckin">
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>Institutionalize in the Organization
<para><xref linkend="section1-instprocess">
</para>
<itemizedlist>
<listitem>
<para>Implement change management
<para><xref linkend="section2-chngmgmt">
</para>
</listitem>
<listitem>
<para>Make &CVSAB; usage part of developer's objectives
<para><xref linkend="section2-objectives">
</para>
</listitem>
<listitem>
<para>Collect metrics on &CVSAB; usage
<para><xref linkend="section2-metrics">
</para>
</listitem>
</itemizedlist>
@ -349,15 +390,20 @@ additions, comments and criticisms to the following email address :
<!-- Using GUI Tools -->
<sect1 id="section1-guitools">
<sect1 id="section1-guitools" xreflabel="GUI Tools">
<title>Using <acronym>GUI</acronym> Tools</title>
<para>The traditional interface available for CVS is the command-line client.
There has also been a slew of GUI client applications that can
<quote>talk</quote> to a &CVSAB; server. These GUI clients provide a
<quote>point and click</quote> interface to the &CVSAB; repository. This
paper recommends using such GUI clients during the initial deployment of
&CVSAB; in an organization.</para>
<quote>point and click</quote> interface to the &CVSAB; repository.
</para>
<sect2 id="section2-useguiclient" xreflabel="&section2-useguiclient;">
<title>&section2-useguiclient;</title>
<para> This paper recommends using such GUI clients during the initial
deployment of &CVSAB; in an organization.</para>
<para>Developers typically use integrated development environments that have
the CM tools integrated into them. These tools minimize the learning for the
@ -367,17 +413,19 @@ find the &CVSAB; command-line interface daunting. The adoption and usage of
&CVSAB; can be improved by using GUI tools for &CVSAB; clients. </para>
<para> GUI tools for &CVSAB; are available at <ulink
url="http://www.cvsgui.org">http://www.cvsgui.org</ulink>. GUI interfaces are available for
most of the popular platforms (Windows, Mac and Linux). In addition, on the
Windows platform there is an <acronym>SCC</acronym> extension that allows
integration of &CVSAB; as the configuration control tool with popular
IDE.</para>
url="http://www.cvsgui.org">http://www.cvsgui.org</ulink>. GUI interfaces
are available for most of the popular platforms (Windows, Mac and Linux).
In addition, on the Windows platform there is an <acronym>SCC</acronym>
extension that allows integration of &CVSAB; as the configuration control
tool with popular IDE.</para>
</sect2>
</sect1>
<!-- Developer Sandbox -->
<sect1 id="section1-devsandbox">
<title>Developer Sandbox</title>
<sect1 id="section1-devsandbox" xreflabel="&section1-devsandbox;">
<title>&section1-devsandbox;</title>
<para>The developer <quote>sandbox</quote> is where each developer keeps his
or her working copy of the code base. In &CVSAB; this is referred to as the
@ -390,8 +438,8 @@ others have to be updated in the sandbox on a regular basis. </para>
<para>The best practices related to developers sandbox are:
</para>
<sect2 id="section2-clockinsync">
<title>Keep System clocks in Sync</title>
<sect2 id="section2-clockinsync" xreflabel="&section2-clockinsync;">
<title>&section2-clockinsync;</title>
<para>&CVSAB; tracks change to source files by using the timestamp on the
file. If each client system date and time is not in sync, there is a
definite possibility of &CVSAB; getting confused. Thus system clocks must be
@ -405,8 +453,8 @@ long as the host operating system has been setup and configured correctly,
</sect2>
<sect2 id="section2-dontshare">
<title>Do not share the sandbox</title>
<sect2 id="section2-dontshare" xreflabel="&section2-dontshare;">
<title>&section2-dontshare;</title>
<para>Sandboxes have to be unique for each developer or purpose. They
should not be used for multiple things at the same time. A sandbox can be a
@ -433,8 +481,8 @@ by them.</para>
</sect2>
<sect2 id="section2-syncup">
<title>Stay in Sync with the repository</title>
<sect2 id="section2-syncup" xreflabel="&section2-syncup;">
<title>&section2-syncup;</title>
<para>To gain the benefits of working within a sandbox as mentioned above,
the developer must keep his or her sandbox in sync with the main repository.
@ -443,8 +491,8 @@ name will ensure that the sandboxes are kept up to date. </para>
</sect2>
<sect2 id="section2-workinside">
<title>Do not work outside the sandbox</title>
<sect2 id="section2-workinside" xreflabel="&section2-workinside;" >
<title>&section2-workinside;</title>
<para>The sandbox can be thought of as a controlled area within which
&CVSAB; can track for changes made to the various source files. Files
@ -457,8 +505,8 @@ work done outside a sandbox. </para>
</sect2>
<sect2 id="section2-cleanupatcompletion">
<title>Cleanup after completion</title>
<sect2 id="section2-cleanupatcompletion" xreflabel="&section2-cleanupatcompletion;">
<title>&section2-cleanupatcompletion;</title>
<para>Make sure that the sandbox is cleaned up after completion of work on
the files. Cleanup can be done in &CVSAB; by using the <command>cvs
@ -470,8 +518,8 @@ compilation in the sandbox. </para>
</sect2>
<sect2 id="section2-checkin">
<title>Check-in Often</title>
<sect2 id="section2-checkin" xreflabel="&section2-checkin;">
<title>&section2-checkin;</title>
<para>To help other developers keep their code in sync with your code, you
must check-in your code often into the &CVSAB; repository. The best
@ -495,22 +543,22 @@ them. Thus, audit trail can be established if necessary. </para>
</sect2>
</sect1>
<sect1 id="section1-serverconfig">
<title>Server Configuration</title>
<sect1 id="section1-serverconfig" xreflabel="&section1-serverconfig;">
<title>&section1-serverconfig;</title>
<para>This section deals with best practices for &CVSAB; server side setup and
configuration.
</para>
<sect2 id="section2-scripting">
<title>Server side scripting</title>
<sect2 id="section2-scripting" xreflabel="&section2-scripting;">
<title>&section2-scripting;</title>
<para>Server side scripting refers to the ability to make &CVSAB; server
execute certain scripts when an event occurs. I am currently not aware of any
best practices in this area. Suggestions are welcome.
</para>
</sect2>
<sect2 id="section2-notification">
<title>Server Notification</title>
<sect2 id="section2-notification" xreflabel="&section2-notification;">
<title>&section2-notification;</title>
<para>The &CVSAB; server can be configured to notify through e-mails in case
of a commit happening. This can be used to verify whether commits are
@ -521,8 +569,10 @@ build automatically restarted.</para>
</sect2>
</sect1>
<sect1 id="section1-branchmerge">
<title>Branching and Merging</title>
<!-- Branching and merging -->
<sect1 id="section1-branchmerge" xreflabel="&section1-branchmerge;">
<title>&section1-branchmerge;</title>
<para> Branching in &CVSAB; splits a project's development into separate,
parallel histories. Changes made on one branch do not affect the other
@ -534,8 +584,8 @@ CVS calculates the changes made on the branch between the point where it
diverged from the trunk and the branch's tip (its most recent state), then
applies those differences to the project at the tip of the trunk. </para>
<sect2 id="section2-branchowner">
<title>Assign Ownership to Trunk and Branches</title>
<sect2 id="section2-branchowner" xreflabel="&section2-branchowner;">
<title>&section2-branchowner;</title>
<para>The main trunk of the source tree and the various branches should have a
owner assigned who will be responsible for. </para>
@ -589,11 +639,14 @@ in time. </para>
</orderedlist>
</sect2>
<sect2 id="section2-tagrelease"> <title>Tag each release</title> <para>After
each release, the entire code base must be tagged with an identifier that
can help in uniquely identifying the release. A tag gives a label to the
collection of revisions represented by one developer's working copy
(usually, that working copy is completely up to date so the tag name is
<sect2 id="section2-tagrelease" xreflabel="&section2-tagrelease;">
<title>&section2-tagrelease;</title>
<para>After each release, the entire code base must be tagged with an
identifier that can help in uniquely identifying the release. A tag gives a
label to the collection of revisions represented by one developer's working
copy (usually, that working copy is completely up to date so the tag name is
attached to the <quote>latest and greatest</quote> revisions in the
repository). </para>
@ -607,8 +660,8 @@ identifier is of the form. </para>
</sect2>
<sect2 id="section2-branchatrelease">
<title>Create a branch after each release</title>
<sect2 id="section2-branchatrelease" xreflabel="&section2-branchatrelease;">
<title>&section2-branchatrelease;</title>
<para>After each software release, once the &CVSAB; repository is tagged, a
branch has to be immediately created. This branch will serve as the bug fix
@ -630,8 +683,8 @@ partition for hot fixes and bug fix releases. </para>
</sect2>
<sect2 id="section2-bugfixbranches">
<title>Make bug fixes to branches only</title>
<sect2 id="section2-bugfixbranches" xreflabel="&section2-bugfixbranches;">
<title>&section2-bugfixbranches;</title>
<para>This practice extends from the previous practice of creating a
separate branch after a major release. The branch will serve as the code
@ -646,8 +699,8 @@ accidentally. </para>
</sect2>
<sect2 id="section2-patchesfrombranches">
<title>Make patch releases from branches only</title>
<sect2 id="section2-patchesfrombranches" xreflabel="&section2-patchesfrombranches;">
<title>&section2-patchesfrombranches;</title>
<para>Since all the bug fixes for a given release are done on its
corresponding branch, the patch releases are made from the branch. This
@ -661,14 +714,16 @@ release tagging practice (see <xref linkend="section2-tagrelease">). </para>
</sect1>
<sect1 id="section1-chgpropagation">
<title>Change Propagation</title>
<!-- Change propagation -->
<sect1 id="section1-chgpropagation" xreflabel="&section1-chgpropagation;">
<title>&section1-chgpropagation;</title>
<para>Change propagation practices explore how changes made to one version of
the application are migrated to other living versions of the application.
</para>
<sect2 id="section2-mergebugfix">
<title>Merge branch with the trunk after release</title>
<sect2 id="section2-mergebugfix" xreflabel="&section2-mergebugfix;">
<title>&section2-mergebugfix;</title>
<para>After each release from a branch, the changes made to the branch
should be merged with the trunk. This ensures that all the bug fixes made
@ -697,18 +752,19 @@ eliminates duplicate merging issues during intermediate merges. </para>
</sect2>
</sect1>
<sect1 id="section1-softwarebuild">
<title>Software Builds</title>
<!-- Software builds -->
<sect1 id="section1-softwarebuild" xreflabel="&section1-softwarebuild;">
<title>&section1-softwarebuild;</title>
<para>This section deals with the best practices for software builds. Build
is the process of creating the application binaries for a software release.
They are done in a periodic manner by the build teams to provide baseline
binaries for daily work. </para>
<sect2 id="section2-bebo">
<title>Build Early and Build Often (<acronym>BEBO</acronym>) </title>
<sect2 id="section2-bebo" xreflabel="&section2-bebo;">
<title>&section2-bebo; (<acronym>BEBO</acronym>) </title>
<para>A slight variation of this adage has been around in the &OPENSOURCE;
<para>A variation of this adage has been around in the &OPENSOURCE;
community called "Release Early and Release Often" for quite some time
albeit for a different reason. BEBO helps a development team identify
issues that can arise from checking in the wrong files. BEBO will address
@ -727,8 +783,8 @@ breaking the build. </para>
</sect2>
<sect2 id="section2-automate">
<title>Automate Build Process completely</title>
<sect2 id="section2-automate" xreflabel="&section2-automate;">
<title>&section2-automate;</title>
<para>Another key practice for software builds is to automate the build
process completely. The automation process must also include automatic
@ -742,8 +798,8 @@ less burdensome. </para>
</sect2>
<sect2 id="section2-ensurecheckin">
<title>All necessary files must be checked before build</title>
<sect2 id="section2-ensurecheckin" xreflabel="&section2-ensurecheckin;">
<title>&section2-ensurecheckin;</title>
<para>This adage sounds trivial at first but this problem is very common
even with experienced development teams due to oversight. The problem of
@ -768,19 +824,20 @@ will contribute a fixed amount will act a good penalty system. </para>
</sect1>
<sect1 id="section1-instprocess">
<title>Institutionalize &CVSAB; in the Organization</title>
<!-- Institutionalize CVS -->
<sect1 id="section1-instprocess" xreflabel="&section1-instprocess;">
<title>&section1-instprocess;</title>
<para>Here we will look at the best practices for institutionalizing &CVSAB;
usage in the organization.
</para>
<sect2 id="section2-chngmgmt">
<title>Implement Change Management Process</title>
<sect2 id="section2-chngmgmt" xreflabel="&section2-chngmgmt;">
<title>&section2-chngmgmt;</title>
<para>All organizations must implement a good Change management process
(<acronym>CMP</acronym>). A good CMP will define how changes are received
and recorded, tracked, executed and delivered. &CVSAB; provides version
(<acronym>CMP</acronym>). A good CMP will define how changes are received,
recorded, tracked, executed and delivered. &CVSAB; provides version
control for your project. Change management addresses the <quote>bigger
picture</quote> of how enhancements and bugs are received, tracked and
closed. &CVSAB; will play a smaller but a very important part in this
@ -793,12 +850,12 @@ here. Please look up other sources of information on change management. </para
</sect2>
<sect2 id="section2-objectives">
<title>Make &CVSAB; Usage part of Objectives</title>
<sect2 id="section2-objectives" xreflabel="&section2-objectives;">
<title>&section2-objectives;</title>
<para>To institutionalize &CVSAB;, it can be made as part of the annual
objectives for the developer to use it as part of his or her project. In addition,
it can also be made as part of the objective for the project manager to deploy
<para>To institutionalize &CVSAB;, it can be made as part of the performance
objectives for the developer to use &CVSAB; in the project. In addition, it
can also be made as part of the objective for the project manager to deploy
&CVSAB; in his or her project. </para>
<para>Compliance of this can then be reviewed as part of the appraisal cycle
@ -806,8 +863,8 @@ for the employee. </para>
</sect2>
<sect2 id="section2-metrics">
<title>Collect metrics on &CVSAB; usage</title>
<sect2 id="section2-metrics" xreflabel="&section2-metrics;">
<title>&section2-metrics;</title>
<para>&CVSAB; usage metrics can be collected in terms of percentage of
deployment in the organization, project size handled etc., This information
@ -817,7 +874,119 @@ tool that will aid them in their daily operations. </para>
</sect2>
</sect1>
<sect1 id="section1-conclusion">
<!-- Case Study -->
<sect1 id="section1-inaction" xreflabel="Best Practices in Action">
<title>Best Practices in Action</title>
<para>The best way to explain the need for these best practices is by
putting together an example of a real world project scenario and show how
exactly will these best practices fit into the <quote>bigger
picture</quote>. Also, a lot of readers have told me that the sections on
<xref linkend="section1-branchmerge"> and <xref
linkend="section1-chgpropagation"> will require examples for better
explanation. Listening to the readers is a Good Thing so I have
put together a particular project scenario and then create a series of
events to show how the best practices, if followed, would help is making
operations smoother. </para>
<sect2 id="section2-inception">
<title>Inception</title>
<para>Consider a software project where version 1.0 has just been put into
production and everyone is done celebrating. The next step is to start
working on the new features of the subsequent release. Also, the users of
the system have started to use it full-time and bug reports of various
levels have started to come in. </para>
<para> Before jumping into new enhancements or bug fixes, the best practices
for <xref linkend="section1-branchmerge"> should be adhered to. Especially
important now is the <xref linkend="section2-tagrelease"> and <xref
linkend="section2-branchatrelease"> practices. By doing so, you have
effectively established two <quote>development environments</quote>, one
for future development and the other for bug fixes and minor enhancements on the last
release.</para>
<para>Let us assume that the release was tagged as
<literallayout>
<literal>release_1_0</literal>
</literallayout>
</para>
<para>Then the branch was created with the branch name
<literallayout>
<literal>release_1_0_patches</literal>
</literallayout>
</para>
</sect2>
<sect2 id="section2-dand">
<title>Development and Delivery</title>
<para>Now, we are ready for business. Let us examine the bug fixes and
enhancements track. Assume that there are three bugs of which two are of a
high priority that needs to go right away (possibly within a week) and the
third can be delivered after some time (say after 4 weeks). Also in the
middle of this schedule we have a regular release scheduled in three weeks.
Considering that we have a busy month ahead, let us see how exactly we can
use the Best practices to ease the days ahead.</para>
<para>Thus we have two teams, one working on the bug fix branch and another
team working on the features for the next release on the main trunk. These
teams must make sure that they start out with the right version in their
sandbox. </para>
<orderedlist>
<listitem>
<para>
The bug fix team will check out using the command line
</para>
<para>
<command>cvs checkout -R -r release_1_0_patches {project name}</command>
</para>
</listitem>
<listitem>
<para>The team that is working on the next team will use the command line
</para>
<para>
<command>cvs checkout -R {project name}</command>
</para>
</listitem>
</orderedlist>
<para> As soon as the bug fix team completes the two top priority bugs,
they will update and commit their changes to the bug fix branch using the command
line
<literallayout>
<command>
cvs update -R -r release_1_0_patches {project name}
cvs commit -R -r release_1_0_patches {project name}
</command>
</literallayout>
</para>
<para>Now, the regular process of build test build is attempted and
a version is ready for delivery. The final version of the source code is
now committed into &CVSAB;. Now, two practices have to be followed.
</para>
<orderedlist>
<listitem>
<para> <xref linkend="section2-tagrelease"> : This ensures that the bug fix
release is tagged correctly and so can be traced out at a later point in
time if necessary.
</para>
</listitem>
<listitem>
<para><xref linkend="section2-mergebugfix"> : This ensures that the bug fix
is merged back into the main trunk ensuring that all future
releases is a truly cumulative delivery.
</para>
</listitem>
</orderedlist>
</sect2>
</sect1>
<sect1 id="section1-conclusion" xreflabel="Conclusion">
<title>Conclusion</title>
<para>These best practices are meant to help software teams get a head start
@ -832,4 +1001,3 @@ evolving document. Please send your comments and ideas to
&GFDL-FILE;
</article>