1090 lines
40 KiB
HTML
1090 lines
40 KiB
HTML
<!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 -> 0.0.0 ->
|
|
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
|
|
-> 3.0.1 -> 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
|
|
cd dist
|
|
cvs -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa login
|
|
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 && autoconf && ./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 && autoconf && ./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 && autoconf && ./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 && autoconf && ./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 && autoconf && ./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 && autoconf && ./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 && autoconf && ./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"> </td>
|
|
|
|
<td width="33%" align="right" valign="top">Update the Webserver</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
</body>
|
|
</html>
|