dan
/
tor-android
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
tor-android/external/privoxy/doc/webserver/developer-manual/newrelease.html

1090 lines
40 KiB
HTML
Raw Normal View History

updated privoxy to 3.0.19-stable
2012-06-28 03:17:49 +00:00
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Linux/x86 (vers 7 December 2008), see www.w3.org">
<title>Releasing a New Version</title>
<meta name="GENERATOR" content=
"Modular DocBook HTML Stylesheet Version 1.79">
<link rel="HOME" title="Privoxy Developer Manual" href="index.html">
<link rel="PREVIOUS" title="Testing Guidelines" href="testing.html">
<link rel="NEXT" title="Update the Webserver" href="webserver-update.html">
<link rel="STYLESHEET" type="text/css" href="../p_doc.css">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css">
body {
background-color: #EEEEEE;
color: #000000;
}
:link { color: #0000FF }
:visited { color: #840084 }
:active { color: #0000FF }
tt.c5 {font-style: italic}
td.c4 {font-weight: bold}
table.c3 {background-color: #E0E0E0}
span.c2 {font-style: italic}
hr.c1 {text-align: left}
</style>
</head>
<body class="SECT1">
<div class="NAVHEADER">
<table summary="Header navigation table" width="100%" border="0"
cellpadding="0" cellspacing="0">
<tr>
<th colspan="3" align="center">Privoxy Developer Manual</th>
</tr>
<tr>
<td width="10%" align="left" valign="bottom"><a href="testing.html"
accesskey="P">Prev</a></td>
<td width="80%" align="center" valign="bottom"></td>
<td width="10%" align="right" valign="bottom"><a href=
"webserver-update.html" accesskey="N">Next</a></td>
</tr>
</table>
<hr class="c1" width="100%">
</div>
<div class="SECT1">
<h1 class="SECT1"><a name="NEWRELEASE" id="NEWRELEASE">6. Releasing a New
Version</a></h1>
<p>When we release versions of <span class="APPLICATION">Privoxy</span>,
our work leaves our cozy secret lab and has to work in the cold
RealWorld[tm]. Once it is released, there is no way to call it back, so
it is very important that great care is taken to ensure that everything
runs fine, and not to introduce problems in the very last minute.</p>
<p>So when releasing a new version, please adhere exactly to the
procedure outlined in this chapter.</p>
<p>The following programs are required to follow this process: <tt class=
"FILENAME">ncftpput</tt> (ncftp), <tt class="FILENAME">scp, ssh</tt>
(ssh), <tt class="FILENAME">gmake</tt> (GNU's version of make), autoconf,
cvs.</p>
<div class="SECT2">
<h2 class="SECT2"><a name="VERSIONNUMBERS" id="VERSIONNUMBERS">6.1.
Version numbers</a></h2>
<p>First you need to determine which version number the release will
have. <span class="APPLICATION">Privoxy</span> version numbers consist
of three numbers, separated by dots, like in X.Y.Z (e.g. 3.0.0),
where:</p>
<ul>
<li>
<p>X, the version major, is rarely ever changed. It is increased by
one if turning a development branch into stable substantially
changes the functionality, user interface or configuration syntax.
Majors 1 and 2 were <span class="APPLICATION">Junkbuster</span>,
and 3 will be the first stable <span class=
"APPLICATION">Privoxy</span> release.</p>
</li>
<li>
<p>Y, the version minor, represents the branch within the major
version. At any point in time, there are two branches being
maintained: The stable branch, with an even minor, say, 2N, in
which no functionality is being added and only bug-fixes are made,
and 2N+1, the development branch, in which the further development
of <span class="APPLICATION">Privoxy</span> takes place. This
enables us to turn the code upside down and inside out, while at
the same time providing and maintaining a stable version. The minor
is reset to zero (and one) when the major is incremented. When a
development branch has matured to the point where it can be turned
into stable, the old stable branch 2N is given up (i.e. no longer
maintained), the former development branch 2N+1 becomes the new
stable branch 2N+2, and a new development branch 2N+3 is
opened.</p>
</li>
<li>
<p>Z, the point or sub version, represents a release of the
software within a branch. It is therefore incremented immediately
before each code freeze. In development branches, only the even
point versions correspond to actual releases, while the odd ones
denote the evolving state of the sources on CVS in between. It
follows that Z is odd on CVS in development branches most of the
time. There, it gets increased to an even number immediately before
a code freeze, and is increased to an odd number again immediately
thereafter. This ensures that builds from CVS snapshots are easily
distinguished from released versions. The point version is reset to
zero when the minor changes.</p>
<p>Stable branches work a little differently, since there should be
little to no development happening in such branches. Remember, only
bugfixes, which presumably should have had some testing before
being committed. Stable branches will then have their version
reported as <tt class="LITERAL">0.0.0</tt>, during that period
between releases when changes are being added. This is to denote
that this code is <span class="emphasis EMPHASIS c2">not for
release</span>. Then as the release nears, the version is bumped
according: e.g. <tt class="LITERAL">3.0.1 -&gt; 0.0.0 -&gt;
3.0.2</tt>.</p>
</li>
</ul>
<p>In summary, the main CVS trunk is the development branch where new
features are being worked on for the next stable series. This should
almost always be where the most activity takes place. There is always
at least one stable branch from the trunk, e.g now it is <tt class=
"LITERAL">3.0</tt>, which is only used to release stable versions. Once
the initial *.0 release of the stable branch has been done, then as a
rule, only bugfixes that have had prior testing should be committed to
the stable branch. Once there are enough bugfixes to justify a new
release, the version of this branch is again incremented Example: 3.0.0
-&gt; 3.0.1 -&gt; 3.0.2, etc are all stable releases from within the
stable branch. 3.1.x is currently the main trunk, and where work on
3.2.x is taking place. If any questions, please post to the devel list
<span class="emphasis EMPHASIS c2">before</span> committing to a stable
branch!</p>
<p>Developers should remember too that if they commit a bugfix to the
stable branch, this will more than likely require a separate submission
to the main trunk, since these are separate development trees within
CVS. If you are working on both, then this would require at least two
separate check outs (i.e main trunk, <span class=
"emphasis EMPHASIS c2">and</span> the stable release branch, which is
<tt class="LITERAL">v_3_0_branch</tt> at the moment).</p>
</div>
<div class="SECT2">
<h2 class="SECT2"><a name="BEFORERELEASE" id="BEFORERELEASE">6.2.
Before the Release: Freeze</a></h2>
<p>The following <span class="emphasis EMPHASIS c2">must be done by one
of the developers</span> prior to each new release.</p>
<ul>
<li>
<p>Make sure that everybody who has worked on the code in the last
couple of days has had a chance to yell <span class=
"QUOTE">"no!"</span> in case they have pending changes/fixes in
their pipelines. Announce the freeze so that nobody will interfere
with last minute changes.</p>
</li>
<li>
<p>Increment the version number (point from odd to even in
development branches!) in <tt class="FILENAME">configure.in</tt>.
(RPM spec files will need to be incremented as well.)</p>
</li>
<li>
<p>If <tt class="FILENAME">default.action</tt> has changed since
last release (i.e. software release or standalone actions file
release), bump up its version info to A.B in this line:</p>
<table class="c3" border="0" width="90%">
<tr>
<td>
<pre class="PROGRAMLISTING">
{+add-header{X-Actions-File-Version: A.B} -filter -no-popups}
</pre>
</td>
</tr>
</table>
<p>Then change the version info in doc/webserver/actions/index.php,
line: '$required_actions_file_version = "A.B";'</p>
</li>
<li>
<p>All documentation should be rebuild after the version bump.
Finished docs should be then be committed to CVS (for those without
the ability to build these). Some docs may require rather obscure
processing tools. <tt class="FILENAME">config</tt>, the man page
(and the html version of the man page), and the PDF docs fall in
this category. REAMDE, the man page, AUTHORS, and config should all
also be committed to CVS for other packagers. The formal docs
should be uploaded to the webserver. See the Section "Updating the
webserver" in this manual for details.</p>
</li>
<li>
<p>The <i class="CITETITLE">User Manual</i> is also used for
context sensitive help for the CGI editor. This is version
sensitive, so that the user will get appropriate help for his/her
release. So with each release a fresh version should be uploaded to
the webserver (this is in addition to the main <i class=
"CITETITLE">User Manual</i> link from the main page since we need
to keep manuals for various versions available). The CGI pages will
link to something like <tt class=
"LITERAL">http://privoxy.org/$(VERSION)/user-manual/</tt>. This
will need to be updated for each new release. There is no Makefile
target for this at this time!!! It needs to be done manually.</p>
</li>
<li>
<p>All developers should look at the <tt class=
"FILENAME">ChangeLog</tt> and make sure noteworthy changes are
referenced.</p>
</li>
<li>
<p><span class="emphasis EMPHASIS c2">Commit all files that were
changed in the above steps!</span></p>
</li>
<li>
<p>Tag all files in CVS with the version number with <span class=
"QUOTE">"<b class="COMMAND">cvs tag v_X_Y_Z</b>"</span>. Don't use
vX_Y_Z, ver_X_Y_Z, v_X.Y.Z (won't work) etc.</p>
</li>
<li>
<p>If the release was in a development branch, increase the point
version from even to odd (X.Y.(Z+1)) again in <tt class=
"FILENAME">configure.in</tt> and commit your change.</p>
</li>
<li>
<p>On the webserver, copy the user manual to a new top-level
directory called <tt class="FILENAME">X.Y.Z</tt>. This ensures that
help links from the CGI pages, which have the version as a prefix,
will go into the right version of the manual. If this is a
development branch release, also symlink <tt class=
"FILENAME">X.Y.(Z-1)</tt> to <tt class="FILENAME">X.Y.Z</tt> and
<tt class="FILENAME">X.Y.(Z+1)</tt> to <tt class="FILENAME">.</tt>
(i.e. dot).</p>
</li>
</ul>
</div>
<div class="SECT2">
<h2 class="SECT2"><a name="THERELEASE" id="THERELEASE">6.3. Building
and Releasing the Packages</a></h2>
<p>Now the individual packages can be built and released. Note that for
GPL reasons the first package to be released is always the source
tarball.</p>
<p>For <span class="emphasis EMPHASIS c2">all</span> types of packages,
including the source tarball, <span class="emphasis EMPHASIS c2">you
must make sure that you build from clean sources by exporting the right
version from CVS into an empty directory</span> (just press return when
asked for a password):</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
mkdir dist # delete or choose different name if it already exists
adding in privoxy directly to Orbot repo
2012-05-03 18:32:18 +00:00
cd dist
cvs -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa login
updated privoxy to 3.0.19-stable
2012-06-28 03:17:49 +00:00
cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa export -r v_X_Y_Z current
</pre>
</td>
</tr>
</table>
<p><span class="emphasis EMPHASIS c2">Do NOT change</span> a single
bit, including, but not limited to version information after export
from CVS. This is to make sure that all release packages, and with
them, all future bug reports, are based on exactly the same code.</p>
<div class="WARNING">
<table class="WARNING" border="1" width="100%">
<tr>
<td class="c4" align="center">Warning</td>
</tr>
<tr>
<td align="left">
<p>Every significant release of Privoxy has included at least
one package that either had incorrect versions of files,
missing files, or incidental leftovers from a previous build
process that gave unknown numbers of users headaches to try to
figure out what was wrong. PLEASE, make sure you are using
pristene sources, and are following the prescribed process!</p>
</td>
</tr>
</table>
</div>
<p>Please find additional instructions for the source tarball and the
individual platform dependent binary packages below. And details on the
Sourceforge release process below that.</p>
<div class="SECT3">
<h3 class="SECT3"><a name="PACK-GUIDELINES" id=
"PACK-GUIDELINES">6.3.1. Note on Privoxy Packaging</a></h3>
<p>Please keep these general guidelines in mind when putting together
your package. These apply to <span class=
"emphasis EMPHASIS c2">all</span> platforms!</p>
<ul>
<li>
<p><span class="APPLICATION">Privoxy</span> <span class=
"emphasis EMPHASIS c2">requires</span> write access to: all
<tt class="FILENAME">*.action</tt> files, all logfiles, and the
<tt class="FILENAME">trust</tt> file. You will need to determine
the best way to do this for your platform.</p>
</li>
<li>
<p>Please include up to date documentation. At a bare
minimum:</p>
<table border="0">
<tbody>
<tr>
<td><tt class="FILENAME">LICENSE</tt> (top-level
directory)</td>
</tr>
</tbody>
</table>
<table border="0">
<tbody>
<tr>
<td><tt class="FILENAME">README</tt> (top-level
directory)</td>
</tr>
</tbody>
</table>
<table border="0">
<tbody>
<tr>
<td><tt class="FILENAME">AUTHORS</tt> (top-level
directory)</td>
</tr>
</tbody>
</table>
<table border="0">
<tbody>
<tr>
<td><tt class="FILENAME">man page</tt> (top-level
directory, Unix-like platforms only)</td>
</tr>
</tbody>
</table>
<table border="0">
<tbody>
<tr>
<td><tt class="FILENAME">The User Manual</tt>
(doc/webserver/user-manual/)</td>
</tr>
</tbody>
</table>
<table border="0">
<tbody>
<tr>
<td><tt class="FILENAME">FAQ</tt> (doc/webserver/faq/)</td>
</tr>
</tbody>
</table>
<p>Also suggested: <tt class="FILENAME">Developer Manual</tt>
(doc/webserver/developer-manual) and <tt class=
"FILENAME">ChangeLog</tt> (top-level directory). <tt class=
"FILENAME">FAQ</tt> and the manuals are HTML docs. There are also
text versions in <tt class="FILENAME">doc/text/</tt> which could
conceivably also be included.</p>
<p>The documentation has been designed such that the manuals are
linked to each other from parallel directories, and should be
packaged that way. <tt class="FILENAME">privoxy-index.html</tt>
can also be included and can serve as a focal point for docs and
other links of interest (and possibly renamed to <tt class=
"FILENAME">index.html</tt>). This should be one level up from the
manuals. There is a link also on this page to an HTMLized version
of the man page. To avoid 404 for this, it is in CVS as
<tt class="FILENAME">doc/webserver/man-page/privoxy-man-page.html</tt>,
and should be included along with the manuals. There is also a
css stylesheets that can be included for better presentation:
<tt class="FILENAME">p_doc.css</tt>. This should be in the same
directory with <tt class="FILENAME">privoxy-index.html</tt>,
(i.e. one level up from the manual directories).</p>
</li>
<li>
<p><tt class="FILENAME">user.action</tt> and <tt class=
"FILENAME">user.filter</tt> are designed for local preferences.
Make sure these do not get overwritten! <tt class=
"FILENAME">config</tt> should not be overwritten either. This has
especially important configuration data in it. <tt class=
"FILENAME">trust</tt> should be left in tact as well.</p>
</li>
<li>
<p>Other configuration files (<tt class=
"FILENAME">default.action</tt> and <tt class=
"FILENAME">default.filter</tt>) should be installed as the new
defaults, but all previously installed configuration files should
be preserved as backups. This is just good manners :-) These
files are likely to change between releases and contain important
new features and bug fixes.</p>
</li>
<li>
<p>Please check platform specific notes in this doc, if you
haven't done <span class="QUOTE">"Privoxy"</span> packaging
before for other platform specific issues. Conversely, please add
any notes that you know are important for your platform (or
contact one of the doc maintainers to do this if you can't).</p>
</li>
<li>
<p>Packagers should do a <span class="QUOTE">"clean"</span>
install of their package after building it. So any previous
installs should be removed first to ensure the integrity of the
newly built package. Then run the package for a while to make
sure there are no obvious problems, before uploading.</p>
</li>
</ul>
</div>
<div class="SECT3">
<h3 class="SECT3"><a name="NEWRELEASE-TARBALL" id=
"NEWRELEASE-TARBALL">6.3.2. Source Tarball</a></h3>
<p>First, <span class="emphasis EMPHASIS c2">make sure that you have
freshly exported the right version into an empty directory</span>.
(See "Building and releasing packages" above). Then run:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
cd current
autoheader &amp;&amp; autoconf &amp;&amp; ./configure
</pre>
</td>
</tr>
</table>
<p>Then do:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
make tarball-dist
</pre>
</td>
</tr>
</table>
<p>To upload the package to Sourceforge, simply issue</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
make tarball-upload
</pre>
</td>
</tr>
</table>
<p>Go to the displayed URL and release the file publicly on
Sourceforge. For the change log field, use the relevant section of
the <tt class="FILENAME">ChangeLog</tt> file.</p>
</div>
<div class="SECT3">
<h3 class="SECT3"><a name="NEWRELEASE-RPM" id="NEWRELEASE-RPM">6.3.3.
SuSE, Conectiva or Red Hat RPM</a></h3>
<p>In following text, replace <tt class="REPLACEABLE c5">dist</tt>
with either <span class="QUOTE">"rh"</span> for Red Hat or
<span class="QUOTE">"suse"</span> for SuSE.</p>
<p>First, <span class="emphasis EMPHASIS c2">make sure that you have
freshly exported the right version into an empty directory</span>.
(See "Building and releasing packages" above).</p>
<p>As the only exception to not changing anything after export from
CVS, now examine the file <tt class=
"FILENAME">privoxy-</tt><tt class="REPLACEABLE c5">dist</tt><tt class="FILENAME">.spec</tt>
and make sure that the version information and the RPM release number
are correct. The RPM release numbers for each version start at one.
Hence it must be reset to one if this is the first RPM for <tt class=
"REPLACEABLE c5">dist</tt> which is built from version X.Y.Z. Check
the <a href=
"http://sourceforge.net/project/showfiles.php?group_id=11118" target=
"_top">file list</a> if unsure. Else, it must be set to the highest
already available RPM release number for that version plus one.</p>
<p>Then run:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
cd current
autoheader &amp;&amp; autoconf &amp;&amp; ./configure
</pre>
</td>
</tr>
</table>
<p>Then do</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
make <tt class="REPLACEABLE c5">dist</tt>-dist
</pre>
</td>
</tr>
</table>
<p>To upload the package to Sourceforge, simply issue</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
make <tt class="REPLACEABLE c5">dist</tt>-upload <tt class=
"REPLACEABLE c5">rpm_packagerev</tt>
</pre>
</td>
</tr>
</table>
<p>where <tt class="REPLACEABLE c5">rpm_packagerev</tt> is the RPM
release number as determined above. Go to the displayed URL and
release the file publicly on Sourceforge. Use the release notes and
change log from the source tarball package.</p>
</div>
<div class="SECT3">
<h3 class="SECT3"><a name="NEWRELEASE-OS2" id="NEWRELEASE-OS2">6.3.4.
OS/2</a></h3>
<p>First, <span class="emphasis EMPHASIS c2">make sure that you have
freshly exported the right version into an empty directory</span>.
(See "Building and releasing packages" above). Then get the OS/2
Setup module:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co os2setup
</pre>
</td>
</tr>
</table>
<p>You will need a mix of development tools. The main compilation
takes place with IBM Visual Age C++. Some ancillary work takes place
with GNU tools, available from various sources like hobbes.nmsu.edu.
Specificially, you will need <tt class="FILENAME">autoheader</tt>,
<tt class="FILENAME">autoconf</tt> and <tt class="FILENAME">sh</tt>
tools. The packaging takes place with WarpIN, available from various
sources, including its home page: <a href=
"http://www.xworkplace.org/" target="_top">xworkplace</a>.</p>
<p>Change directory to the <tt class="FILENAME">os2setup</tt>
directory. Edit the os2build.cmd file to set the final executable
filename. For example,</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
installExeName='privoxyos2_setup_X.Y.Z.exe'
</pre>
</td>
</tr>
</table>
<p>Next, edit the <tt class="FILENAME">IJB.wis</tt> file so the
release number matches in the <tt class="FILENAME">PACKAGEID</tt>
section:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
PACKAGEID="Privoxy Team\Privoxy\Privoxy Package\X\Y\Z"
</pre>
</td>
</tr>
</table>
<p>You're now ready to build. Run:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
os2build
</pre>
</td>
</tr>
</table>
<p>You will find the WarpIN-installable executable in the <tt class=
"FILENAME">./files</tt> directory. Upload this anonymously to
<tt class="FILENAME">uploads.sourceforge.net/incoming</tt>, create a
release for it, and you're done. Use the release notes and Change Log
from the source tarball package.</p>
</div>
<div class="SECT3">
<h3 class="SECT3"><a name="NEWRELEASE-SOLARIS" id=
"NEWRELEASE-SOLARIS">6.3.5. Solaris</a></h3>
<p>Login to Sourceforge's compilefarm via ssh:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
ssh cf.sourceforge.net
</pre>
</td>
</tr>
</table>
<p>Choose the right operating system (not the Debian one). When
logged in, <span class="emphasis EMPHASIS c2">make sure that you have
freshly exported the right version into an empty directory</span>.
(See "Building and releasing packages" above). Then run:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
cd current
autoheader &amp;&amp; autoconf &amp;&amp; ./configure
</pre>
</td>
</tr>
</table>
<p>Then run</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
gmake solaris-dist
</pre>
</td>
</tr>
</table>
<p>which creates a gzip'ed tar archive. Sadly, you cannot use
<b class="COMMAND">make solaris-upload</b> on the Sourceforge machine
(no ncftpput). You now have to manually upload the archive to
Sourceforge's ftp server and release the file publicly. Use the
release notes and Change Log from the source tarball package.</p>
</div>
<div class="SECT3">
<h3 class="SECT3"><a name="NEWRELEASE-WINDOWS" id=
"NEWRELEASE-WINDOWS">6.3.6. Windows</a></h3>
<p>You should ensure you have the latest version of Cygwin (from
<a href="http://www.cygwin.com/" target=
"_top">http://www.cygwin.com/</a>). Run the following commands from
within a Cygwin bash shell.</p>
<p>First, <span class="emphasis EMPHASIS c2">make sure that you have
freshly exported the right version into an empty directory</span>.
(See "Building and releasing packages" above). Then get the Windows
setup module:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co winsetup
</pre>
</td>
</tr>
</table>
<p>Then you can build the package. This is fully automated, and is
controlled by <tt class="FILENAME">winsetup/GNUmakefile</tt>. All you
need to do is:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
cd winsetup
make
</pre>
</td>
</tr>
</table>
<p>Now you can manually rename <tt class=
"FILENAME">privoxy_setup.exe</tt> to <tt class=
"FILENAME">privoxy_setup_X_Y_Z.exe</tt>, and upload it to
SourceForge. When releasing the package on SourceForge, use the
release notes and Change Log from the source tarball package.</p>
</div>
<div class="SECT3">
<h3 class="SECT3"><a name="NEWRELEASE-DEBIAN" id=
"NEWRELEASE-DEBIAN">6.3.7. Debian</a></h3>
<p>First, <span class="emphasis EMPHASIS c2">make sure that you have
freshly exported the right version into an empty directory</span>.
(See "Building and releasing packages" above). Then add a log entry
to <tt class="FILENAME">debian/changelog</tt>, if it is not already
there, for example by running:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
debchange -v 3.0.19-stable-1 "New upstream version"
</pre>
</td>
</tr>
</table>
<p>Then, run:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
dpkg-buildpackage -rfakeroot -us -uc -b
</pre>
</td>
</tr>
</table>
<p>This will create <tt class=
"FILENAME">../privoxy_3.0.19-stable-1_i386.deb</tt> which can be
uploaded. To upload the package to Sourceforge, simply issue</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
make debian-upload
</pre>
</td>
</tr>
</table>
</div>
<div class="SECT3">
<h3 class="SECT3"><a name="NEWRELEASE-MACOSX" id=
"NEWRELEASE-MACOSX">6.3.8. Mac OS X</a></h3>
<p>First, <span class="emphasis EMPHASIS c2">make sure that you have
freshly exported the right version into an empty directory</span>.
(See "Building and releasing packages" above). Then get the Mac OS X
setup module:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co osxsetup
</pre>
</td>
</tr>
</table>
<p>Then run:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
cd osxsetup
build
</pre>
</td>
</tr>
</table>
<p>This will run <tt class="FILENAME">autoheader</tt>, <tt class=
"FILENAME">autoconf</tt> and <tt class="FILENAME">configure</tt> as
well as <tt class="FILENAME">make</tt>. Finally, it will copy over
the necessary files to the ./osxsetup/files directory for further
processing by <tt class="FILENAME">PackageMaker</tt>.</p>
<p>Bring up PackageMaker with the PrivoxyPackage.pmsp definition
file, modify the package name to match the release, and hit the
"Create package" button. If you specify ./Privoxy.pkg as the output
package name, you can then create the distributable zip file with the
command:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg
</pre>
</td>
</tr>
</table>
<p>You can then upload <tt class=
"FILENAME">privoxyosx_setup_x.y.z.zip</tt> anonymously to <tt class=
"FILENAME">uploads.sourceforge.net/incoming</tt>, create a release
for it, and you're done. Use the release notes and Change Log from
the source tarball package.</p>
</div>
<div class="SECT3">
<h3 class="SECT3"><a name="NEWRELEASE-FREEBSD" id=
"NEWRELEASE-FREEBSD">6.3.9. FreeBSD</a></h3>
<p>Login to Sourceforge's compile-farm via ssh:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
ssh cf.sourceforge.net
</pre>
</td>
</tr>
</table>
<p>Choose the right operating system. When logged in, <span class=
"emphasis EMPHASIS c2">make sure that you have freshly exported the
right version into an empty directory</span>. (See "Building and
releasing packages" above). Then run:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
cd current
autoheader &amp;&amp; autoconf &amp;&amp; ./configure
</pre>
</td>
</tr>
</table>
<p>Then run:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
gmake freebsd-dist
</pre>
</td>
</tr>
</table>
<p>which creates a gzip'ed tar archive. Sadly, you cannot use
<b class="COMMAND">make freebsd-upload</b> on the Sourceforge machine
(no ncftpput). You now have to manually upload the archive to
Sourceforge's ftp server and release the file publicly. Use the
release notes and Change Log from the source tarball package.</p>
</div>
<div class="SECT3">
<h3 class="SECT3"><a name="NEWRELEASE-HPUX" id=
"NEWRELEASE-HPUX">6.3.10. HP-UX 11</a></h3>
<p>First, <span class="emphasis EMPHASIS c2">make sure that you have
freshly exported the right version into an empty directory</span>.
(See "Building and releasing packages" above). Then run:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
cd current
autoheader &amp;&amp; autoconf &amp;&amp; ./configure
</pre>
</td>
</tr>
</table>
<p>Then do FIXME.</p>
</div>
<div class="SECT3">
<h3 class="SECT3"><a name="NEWRELEASE-AMIGA" id=
"NEWRELEASE-AMIGA">6.3.11. Amiga OS</a></h3>
<p>First, <span class="emphasis EMPHASIS c2">make sure that you have
freshly exported the right version into an empty directory</span>.
(See "Building and releasing packages" above). Then run:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
cd current
autoheader &amp;&amp; autoconf &amp;&amp; ./configure
</pre>
</td>
</tr>
</table>
<p>Then do FIXME.</p>
</div>
<div class="SECT3">
<h3 class="SECT3"><a name="NEWRELEASE-AIX" id=
"NEWRELEASE-AIX">6.3.12. AIX</a></h3>
<p>Login to Sourceforge's compilefarm via ssh:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
ssh cf.sourceforge.net
</pre>
</td>
</tr>
</table>
<p>Choose the right operating system. When logged in, <span class=
"emphasis EMPHASIS c2">make sure that you have freshly exported the
right version into an empty directory</span>. (See "Building and
releasing packages" above). Then run:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
cd current
autoheader &amp;&amp; autoconf &amp;&amp; ./configure
</pre>
</td>
</tr>
</table>
<p>Then run:</p>
<table class="c3" border="0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
make aix-dist
</pre>
</td>
</tr>
</table>
<p>which creates a gzip'ed tar archive. Sadly, you cannot use
<b class="COMMAND">make aix-upload</b> on the Sourceforge machine (no
ncftpput). You now have to manually upload the archive to
Sourceforge's ftp server and release the file publicly. Use the
release notes and Change Log from the source tarball package.</p>
</div>
</div>
<div class="SECT2">
<h2 class="SECT2"><a name="RELEASING" id="RELEASING">6.4. Uploading and
Releasing Your Package</a></h2>
<p>After the package is ready, it is time to upload it to SourceForge,
and go through the release steps. The upload is done via FTP:</p>
<ul>
<li>
<p>Upload to: <a href="ftp://upload.sourceforge.net/incoming"
target="_top">ftp://upload.sourceforge.net/incoming</a></p>
</li>
<li>
<p>user: <tt class="LITERAL">anonymous</tt></p>
</li>
<li>
<p>password: <tt class=
"LITERAL">ijbswa-developers@lists.sourceforge.net</tt></p>
</li>
</ul>
<p>Or use the <b class="COMMAND">make</b> targets as described
above.</p>
<p>Once this done go to <a href=
"https://sourceforge.net/project/admin/editpackages.php?group_id=11118"
target=
"_top">https://sourceforge.net/project/admin/editpackages.php?group_id=11118</a>,
making sure you are logged in. Find your target platform in the second
column, and click <tt class="LITERAL">Add Release</tt>. You will then
need to create a new release for your package, using the format of
<tt class="LITERAL">$VERSION ($CODE_STATUS)</tt>, e.g. <span class=
"emphasis EMPHASIS c2">3.0.19 (beta)</span>.</p>
<p>Now just follow the prompts. Be sure to add any appropriate Release
notes. You should see your freshly uploaded packages in <span class=
"QUOTE">"Step 2. Add Files To This Release"</span>. Check the
appropriate box(es). Remember at each step to hit the <span class=
"QUOTE">"Refresh/Submit"</span> buttons! You should now see your
file(s) listed in Step 3. Fill out the forms with the appropriate
information for your platform, being sure to hit <span class=
"QUOTE">"Update"</span> for each file. If anyone is monitoring your
platform, check the <span class="QUOTE">"email"</span> box at the very
bottom to notify them of the new package. This should do it!</p>
<p>If you have made errors, or need to make changes, you can go through
essentially the same steps, but select <tt class="LITERAL">Edit
Release</tt>, instead of <tt class="LITERAL">Add Release</tt>.</p>
</div>
<div class="SECT2">
<h2 class="SECT2"><a name="AFTERRELEASE" id="AFTERRELEASE">6.5. After
the Release</a></h2>
<p>When all (or: most of the) packages have been uploaded and made
available, send an email to the <a href=
"mailto:ijbswa-announce@lists.sourceforge.net" target="_top">announce
mailing list</a>, Subject: "Version X.Y.Z available for download". Be
sure to include the <a href=
"http://sourceforge.net/project/showfiles.php?group_id=11118" target=
"_top">download location</a>, the release notes and the Changelog.
Also, post an updated News item on the project page Sourceforge, and
update the Home page and docs linked from the Home page (see below).
Other news sites and release oriented sites, such as Freshmeat, should
also be notified.</p>
</div>
</div>
<div class="NAVFOOTER">
<hr class="c1" width="100%">
<table summary="Footer navigation table" width="100%" border="0"
cellpadding="0" cellspacing="0">
<tr>
<td width="33%" align="left" valign="top"><a href="testing.html"
accesskey="P">Prev</a></td>
<td width="34%" align="center" valign="top"><a href="index.html"
accesskey="H">Home</a></td>
<td width="33%" align="right" valign="top"><a href=
"webserver-update.html" accesskey="N">Next</a></td>
</tr>
<tr>
<td width="33%" align="left" valign="top">Testing Guidelines</td>
<td width="34%" align="center" valign="top">&nbsp;</td>
<td width="33%" align="right" valign="top">Update the Webserver</td>
</tr>
</table>
</div>
</body>
</html>