sintonia/livesupport/doc/release.html

166 lines
8.0 KiB
HTML

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>LiveSupport release process documentation</title>
<meta content="$Author: maroy $" name="author">
</head>
<body>
<h1>Preface</h1>
This document is part of the <a href="http://livesupport.campware.org/">LiveSupport</a>
project, Copyright © 2004 <a href="http://www.mdlf.org/">Media
Development Loan Fund</a>, under the GNU <a
href="http://www.gnu.org/licenses/gpl.html">GPL</a>.<br>
<ul>
<li>Author: $Author: maroy $</li>
<li>Version: $Revision: 1.5 $</li>
<li>Location: $Source: /home/paul/cvs2svn-livesupport/newcvsrepo/livesupport/doc/release.html,v $</li>
</ul>
<h1>Scope</h1>
This document describes the process of releasing a new version of
LiveSupport. Obviously this document is only relevant to people who
have the rights and permissions to make such a release.<br>
<h1>Introduction</h1>
For all the releases of LiveSupport to remain consistent, it is
preferable to have a repeatable release process, which will be followed
when creating releases. This ensures that no matter who creates the
releases, they will remain similar.<br>
<br>
The release process boils down to the following steps:<br>
<ul>
<li>getting LiveSupport sources</li>
<li>checking the distribution script<br>
</li>
<li>creating release tarballs</li>
<li>testing the tarballs</li>
<li>creating Debian packages<br>
</li>
<li>tagging the sources</li>
<li>publishing the tarballs</li>
<li>announcing the release<br>
</li>
</ul>
<h1>Getting LiveSupport sources</h1>
It is assumed that the person doing the release has a read/write access
to the LiveSupport version control system. As a first step of the
release process, a fresh copy of the version control repository is
check out, so as to insure that:<br>
<ul>
<li>the release contains exactly the files that are in the version
control system</li>
<li>there are no generated files in the release</li>
</ul>
To get a fresh copy of the LiveSupport repository, execute the
following in an empty directory:<br>
<br>
<pre><code>cvs -z3 -d :ext:&lt;username&gt;@netfinity-5.mdlf.org:/home/cvs checkout -P livesupport</code><br></pre>
<br>
Where <code>&lt;username&gt;</code> is the user name for accessing the
repository of the person making the release.<br>
<h1>Checking the distribution script</h1>
It is advisable to check the installation script <code>bin/dist.sh</code>,
to make sure it refers to up-to-date information from the development
environment.<br>
<br>
The most important aspect to check is that the specific versions of
tools mentioned in the distribution script are in sync with the tools
compiled by the master <code>Makefile</code> under the target <code>tools_setup</code>.
To check this, compare tool version variables in the two files, e.g. <code>BOOST_VERSION</code>
from <code>Makefile</code> with <code>boost_version</code> from <code>bin/dist.sh</code>.
Make sure to check the versions for all the tools mentioned in these
files. Also check that there are no tools missing from the distribution
script that are mentioned in the master <code>Makefile</code>.<br>
<h1>Creating release tarballs<br>
</h1>
To create the release tarballs, invoke the distribution script <code>bin/dist.sh</code>,
with the release version as its single parameter:<br>
<br>
<pre><code>./bin/dist.sh --version &lt;ls-version&gt;<br></code></pre>
<br>
This will create two tarballs in the current directory:<br>
<ul>
<li><code>livesupport-&lt;ls-version&gt;.tar.bz2</code></li>
<li><code>livesupport-libraries-&lt;ls-version&gt;.tar.bz2</code></li>
</ul>
<h1>Testing the tarballs</h1>
Having broken releases is very annoying, thus it is highly recommended
that the release tarballs are tested on a plain vanilla system. To test
the tarballs, follow the procedure described in the LiveSupport <a
href="install.html">installation document</a>.<br>
<br>
Do not publish tarballs that have not been tested, or are known to be
broken.<br>
<h1>Creating Debian packages</h1>
After the source tarballs have been tested, Debian source and binary
packages can be created. To do so, upload the source tarballs to a
Debian system, and do the following:<br>
<br>
<pre><code>tar xfj livesupport-&lt;ls-version&gt;.tar.bz2<br>tar xfj livesupport-libraries-&lt;ls-version&gt;.tar.bz2<br>cd livesupport-&lt;ls-version&gt;<br>./bin/createDebianPackages.sh -d .. -v &lt;ls-version&gt; -m "Package Maintainer &lt;maintainer@foo.bar&gt;" -o ..<br>cd ..<br></code></pre>
<br>
The above command will create the Debain source package files next to
the original source tarballs. The script will generate the following
files, making up the Debian source package:<br>
<br>
<pre><code>livesupport_&lt;ls-version&gt;-1.dsc<br></code><code>livesupport_&lt;ls-version&gt;-1.diff.gz<br></code><code>livesupport_&lt;ls-version&gt;.orig.tar.gz<br><br></code></pre>
Based on the source packages, the Debian package management system can
build the binaries for the current target platform, provided all the
necessary packages required to build are installed on the system. For a
list of the necessary packages, please consult the debian/control file
in extracted debianized source tree generated below.<br>
Building is best done
in an empty directory as follows:<br>
<br>
<pre><code>rm -rf debian_build<br>mkdir debian_build<br>cd debian_build<br></code>dpkg-source -x ../livesupport_&lt;ls_version&gt;-1.dsc<br>cd livesupport-&lt;ls-version&gt;<br>dpkg-buildpackage -rfakeroot<br>cd ../..<br><br></pre>
The above commands will result in the following debian packages:<br>
<br>
<pre><code>livesupport-libs_&lt;ls-version&gt;-1_&lt;arch&gt;.deb<br></code><code>livesupport-station_&lt;ls-version&gt;-1_&lt;arch&gt;.deb<br></code><code>livesupport-studio_&lt;ls-version&gt;-1_&lt;arch&gt;.deb</code><br></pre>
<pre><code></code><code></code></pre>
<h1>Tagging the sources</h1>
After the tarballs have been tested, the release can be finalized. As a
first step, the current state of the LiveSupport version control
repository has to be tagged, so that the the very versions in the
release can be retrieved at any later date. To tag the repository,
issue the following command from the LiveSupport checked out source
directory:<br>
<br>
<pre><code>cvs tag livesupport_&lt;ls-version&gt;<br></code></pre>
<br>
This will tag the current state of the repository with the tag <code>livesupport_&lt;ls-version&gt;</code>,
enabling later retrieval of this specific state. Please note that since
CVS does not support dots (<code>'.'</code>) in tags, the dots in the
version number are replaced by underscore (<code>'_'</code>) when
tagging. Thus, <code>livesupport-0.9.1</code> is tagged as <code>livesupport-0_9_1</code>,
for example.<br>
<h1>Publishing the tarballs</h1>
To make the release available to the public, the created tarballs have
to be published. This is done by making the files accessible under the
LiveSupport project page on SourceForge: <code>http://sourceforge.net/projects/livesupport</code><span
style="font-family: monospace;"></span><code></code>. Currently, only
MDLF support staff have access to publish into this
space, so after creating the tarballs, one should contact them
personally to publish the files.<br>
<h1>Announcing the release</h1>
For the public to be aware of the new release, it has to be announced.
This is primarily done on the Campware site, but also on other
meta-sites, like freshmeat. In particular, the following announcements
are made:<br>
<ul>
<li>Campware.org site.</li>
<li>Freshmeat.net.</li>
<li>Press releases/announcements go to:</li>
<ul>
<li>NewsForge (<a class="moz-txt-link-freetext"
href="http://www.newsforge.com/">http://www.newsforge.com</a>)</li>
<li> PRweb (<a class="moz-txt-link-freetext"
href="http://www.prweb.com/">http://www.prweb.com</a>)</li>
<li>MDLF's press person</li>
<li> LiveSupport developers' list, urging everyone to send it to
friends and contacts</li>
<li>Other Campware developers' lists on major releases</li>
<li> Other mailing lists and friendly/relevant organizations</li>
</ul>
</ul>
<br>
</body>
</html>