<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
-
<html>
<head>
<title>Releasing a New Version</title>
- <meta name="GENERATOR" content=
- "Modular DocBook HTML Stylesheet Version 1.79">
+ <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">
+ <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
-
-<body class="SECT1" bgcolor="#EEEEEE" text="#000000" link="#0000FF" vlink=
-"#840084" alink="#0000FF">
+<body class="SECT1" bgcolor="#EEEEEE" text="#000000" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="NAVHEADER">
- <table summary="Header navigation table" width="100%" border="0"
- cellpadding="0" cellspacing="0">
+ <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="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>
+ <td width="10%" align="right" valign="bottom"><a href="webserver-update.html" accesskey="N">Next</a></td>
</tr>
</table>
<hr align="left" 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,
+ <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>
-
+ <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=
+ <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>
+ <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"><i class="EMPHASIS">not
- for release</i></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>
+ <p>Z, the point or sub version, represents a release of the software within a branch. It is therefore
+ incremented immediately after each software release. 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"><i class="EMPHASIS">not for release</i></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"><i class="EMPHASIS">before</i></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"><i class=
- "EMPHASIS">and</i></span> the stable release branch, which is
- <tt class="LITERAL">v_3_0_branch</tt> at the moment).</p>
+ <p>In summary, the main Git 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"><i class=
+ "EMPHASIS">before</i></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 Git. If you
+ are working on both, then this would require at least two separate check outs (i.e main trunk, <span class=
+ "emphasis"><i class="EMPHASIS">and</i></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"><i class="EMPHASIS">must be
- done by one of the developers</i></span> prior to each new release.</p>
-
+ <h2 class="SECT2"><a name="BEFORERELEASE" id="BEFORERELEASE">6.2. Before the Release</a></h2>
+ <p>The following <span class="emphasis"><i class="EMPHASIS">must be done by one of the developers</i></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>
+ <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>
+ <p>Update the code status (CODE_STATUS="xxx") in configure.in to one of "alpha", "beta" or "stable".</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>
-
+ <p>Rebuild configure and GNUMakefile to make sure the updated values are being used.</p>
<table border="0" bgcolor="#E0E0E0" width="90%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- {+add-header{X-Actions-File-Version: A.B} -filter -no-popups}
-</pre>
+ <pre class="PROGRAMLISTING">$ autoheader && autoconf # rebuild configure
+$ ./configure # rebuild GNUmakefile</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) 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>
+ <p><b class="COMMAND">make dok-release</b> to update the sgml documentation source files.</p>
+ </li>
+ <li>
+ <p>If action file processing has changed and is not backward-compatible, make sure the
+ "for-privoxy-version=x.y.z" minimum version number in default.action.master has been updated:</p>
+ <table border="0" bgcolor="#E0E0E0" width="90%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">{{settings}}
+#############################################################################
+#MASTER# COMMENT: The minimum Privoxy version:
+for-privoxy-version=3.0.11</pre>
+ </td>
+ </tr>
+ </table>
</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>
+ <p>Create the change log:</p>
+ <table border="0" bgcolor="#E0E0E0" width="90%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING"> $ git tag
+ # to see the tags
+ $ git log [last release tag]..HEAD > /tmp/log
+ # get the commit log since the last release
+ $ utils/makeChangeLog /tmp/log > /tmp/change.log
+ # reformat the commit log</pre>
+ </td>
+ </tr>
+ </table>
+ <p>Edit <tt class="FILENAME">/tmp/change.log</tt> to remove trivial changes and group the changes under
+ general headings like:</p>
+ <table border="0" bgcolor="#E0E0E0" width="90%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">- Bug fixes:
+- Action file improvements:
+- Filter file improvements:
+- General improvements:
+- Documentation improvements:
+- Build system improvements:
+- Code cleanups:
+- Privoxy-Log-Parser:
+- Privoxy-Regression-Test:</pre>
+ </td>
+ </tr>
+ </table>
+ <p>Add the contents of <tt class="FILENAME">/tmp/change.log</tt> to the start of <tt class=
+ "FILENAME">ChangeLog</tt> and re-create <tt class="FILENAME">doc/source/changelog.sgml</tt>:</p>
+ <table border="0" bgcolor="#E0E0E0" width="90%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
+ $ utils/changelog2doc.pl /tmp/change.log >| doc/source/changelog.sgml</pre>
+ </td>
+ </tr>
+ </table>
</li>
-
<li>
- <p>All developers should look at the <tt class=
- "FILENAME">ChangeLog</tt> and make sure noteworthy changes are
+ <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"><i class="EMPHASIS">Commit all files that
- were changed in the above steps!</i></span></p>
+ <p>All documentation should be rebuilt:</p>
+ <table border="0" bgcolor="#E0E0E0" width="90%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING"> $ make man
+ $ make dok
+ $ make dok-man
+ $ make dok-tidy
+ $ make config-file</pre>
+ </td>
+ </tr>
+ </table>Finished docs should be then be committed to Git (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) fall in this category. README, the man page, AUTHORS, and config should all
+ also be committed to Git for other packagers. The formal docs should be uploaded to the webserver. See the
+ section <a href="webserver-update.html" target="_top">"Updating the webserver"</a> in this manual for
+ details.
+ </li>
+ <li>
+ <p><span class="emphasis"><i class="EMPHASIS">Commit all files that were changed in the above
+ steps!</i></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>
+ <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>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>
+ <p>Tag all files in Git 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>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>
+ <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"><i class="EMPHASIS">all</i></span> types
- of packages, including the source tarball, <span class=
- "emphasis"><i class="EMPHASIS">you must make sure that you build from
- clean sources by exporting the right version from CVS into an empty
- directory</i></span> (just press return when asked for a password):</p>
-
+ <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"><i class="EMPHASIS">all</i></span> types of packages, including the source tarball,
+ <span class="emphasis"><i class="EMPHASIS">you must make sure that you build from clean sources by exporting the
+ right version from Git into an empty directory</i></span> (just press return when asked for a password):</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- mkdir dist # delete or choose different name if it already exists
+ <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>
+ 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"><i class="EMPHASIS">Do NOT change</i></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>
-
+ <p><span class="emphasis"><i class="EMPHASIS">Do NOT change</i></span> a single bit, including, but not limited
+ to version information after export from Git. 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 align="center"><b>Warning</b></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>
+ <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>
-
+ <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"><i class=
- "EMPHASIS">all</i></span> platforms!</p>
-
+ <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"><i class="EMPHASIS">all</i></span> platforms!</p>
<ul>
<li>
- <p><span class="APPLICATION">Privoxy</span> <span class=
- "emphasis"><i class="EMPHASIS">requires</i></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>
+ <p><span class="APPLICATION">Privoxy</span> <span class="emphasis"><i class="EMPHASIS">requires</i></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>
-
+ <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>
+ <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>
+ <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>
+ <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>
+ <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>
+ <td><tt class="FILENAME">The User Manual</tt> (doc/webserver/user-manual/)</td>
</tr>
</tbody>
</table>
-
<table border="0">
<tbody>
<tr>
</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>
+ <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 Git 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>
+ <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>
+ <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>
+ <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>
+ <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"><i class="EMPHASIS">make sure that
- you have freshly exported the right version into an empty
- directory</i></span>. (See "Building and releasing packages" above).
- Then run:</p>
-
+ <h3 class="SECT3"><a name="NEWRELEASE-TARBALL" id="NEWRELEASE-TARBALL">6.3.2. Source Tarball</a></h3>
+ <p>First, <span class="emphasis"><i class="EMPHASIS">make sure that you have freshly exported the right version
+ into an empty directory</i></span>. (See "Building and releasing packages" above). Then run:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- cd current
- autoheader && autoconf && ./configure
-</pre>
+ <pre class="PROGRAMLISTING"> cd current
+ autoheader && autoconf && ./configure</pre>
</td>
</tr>
</table>
-
<p>Then do:</p>
-
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- make tarball-dist
-</pre>
+ <pre class="PROGRAMLISTING"> make tarball-dist</pre>
</td>
</tr>
</table>
-
<p>To upload the package to Sourceforge, simply issue</p>
-
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- make tarball-upload
-</pre>
+ <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>
+ <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"><i>dist</i></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"><i class="EMPHASIS">make sure that
- you have freshly exported the right version into an empty
- directory</i></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"><i>dist</i></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"><i>dist</i></tt> which is built from version X.Y.Z.
- Check the <a href=
- "https://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>
-
+ <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"><i>dist</i></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"><i class="EMPHASIS">make sure that you have freshly exported the right version
+ into an empty directory</i></span>. (See "Building and releasing packages" above).</p>
+ <p>As the only exception to not changing anything after export from Git, now examine the file <tt class=
+ "FILENAME">privoxy-</tt><tt class="REPLACEABLE"><i>dist</i></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"><i>dist</i></tt> which is built from version X.Y.Z. Check the <a href=
+ "https://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 border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- cd current
- autoheader && autoconf && ./configure
-</pre>
+ <pre class="PROGRAMLISTING"> cd current
+ autoheader && autoconf && ./configure</pre>
</td>
</tr>
</table>
-
<p>Then do</p>
-
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- make <tt class="REPLACEABLE"><i>dist</i></tt>-dist
-</pre>
+ <pre class="PROGRAMLISTING"> make <tt class="REPLACEABLE"><i>dist</i></tt>-dist</pre>
</td>
</tr>
</table>
-
<p>To upload the package to Sourceforge, simply issue</p>
-
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- make <tt class="REPLACEABLE"><i>dist</i></tt>-upload <tt class=
-"REPLACEABLE"><i>rpm_packagerev</i></tt>
-</pre>
+ <pre class="PROGRAMLISTING"> make <tt class="REPLACEABLE"><i>dist</i></tt>-upload <tt class=
+ "REPLACEABLE"><i>rpm_packagerev</i></tt></pre>
</td>
</tr>
</table>
-
- <p>where <tt class="REPLACEABLE"><i>rpm_packagerev</i></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>
+ <p>where <tt class="REPLACEABLE"><i>rpm_packagerev</i></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"><i class="EMPHASIS">make sure that
- you have freshly exported the right version into an empty
- directory</i></span>. (See "Building and releasing packages" above).
- Then get the OS/2 Setup module:</p>
-
+ <h3 class="SECT3"><a name="NEWRELEASE-OS2" id="NEWRELEASE-OS2">6.3.4. OS/2</a></h3>
+ <p>First, <span class="emphasis"><i class="EMPHASIS">make sure that you have freshly exported the right version
+ into an empty directory</i></span>. (See "Building and releasing packages" above). Then get the OS/2 Setup
+ module:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
- cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co os2setup
-</pre>
+ 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>
-
+ <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 border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- installExeName='privoxyos2_setup_X.Y.Z.exe'
-</pre>
+ <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>
-
+ <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 border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- PACKAGEID="Privoxy Team\Privoxy\Privoxy Package\X\Y\Z"
-</pre>
+ <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 border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- os2build
-</pre>
+ <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>
+ <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>
-
+ <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 border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- ssh cf.sourceforge.net
-</pre>
+ <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"><i class="EMPHASIS">make sure that
- you have freshly exported the right version into an empty
- directory</i></span>. (See "Building and releasing packages" above).
- Then run:</p>
-
+ <p>Choose the right operating system (not the Debian one). When logged in, <span class="emphasis"><i class=
+ "EMPHASIS">make sure that you have freshly exported the right version into an empty directory</i></span>. (See
+ "Building and releasing packages" above). Then run:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- cd current
- autoheader && autoconf && ./configure
-</pre>
+ <pre class="PROGRAMLISTING"> cd current
+ autoheader && autoconf && ./configure</pre>
</td>
</tr>
</table>
-
<p>Then run</p>
-
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- gmake solaris-dist
-</pre>
+ <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>
+ <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>Use the <a href=
- "http://www.fruitbat.org/Cygwin/index.html#cygwincirca" target=
- "_top">Cygwin Time Machine</a> to install the last 1.5 version of
- Cygwin. Run the following commands from within the Cygwin 1.5 bash
- shell.</p>
-
- <p>First, <span class="emphasis"><i class="EMPHASIS">make sure that
- you have freshly exported the right version into an empty
- directory</i></span>. (See "Building and releasing packages" above).
- Then get the Windows setup module:</p>
-
+ <h3 class="SECT3"><a name="NEWRELEASE-WINDOWS" id="NEWRELEASE-WINDOWS">6.3.6. Windows</a></h3>
+ <p>Note that the docbook generated files might need some hand editing, so the Windows build makefile does not
+ rebuild the docs.</p>
+ <p>First, <span class="emphasis"><i class="EMPHASIS">make sure that you have freshly exported the right version
+ into an empty directory</i></span>. (See "Building and releasing packages" above).</p>
+ <p>Then you can build the package. This is fully automated, and is controlled by <tt class=
+ "FILENAME">windows/GNUmakefile</tt>. All you need to do is:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co winsetup
-</pre>
+ <pre class="PROGRAMLISTING"> cd windows
+ make</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>
-
+ <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 the <tt class="FILENAME">build</tt> directory to <tt class=
+ "FILENAME">privoxy_X.Y.Z</tt>. Create a .zip file of the newly renamed <tt class="FILENAME">privoxy_X.Y.Z</tt>
+ directory, GPG sign the installer and zip file,</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- cd winsetup
- make
-</pre>
+ <pre class="PROGRAMLISTING"> $ gpg --armor --detach --sign <tt class=
+ "FILENAME">privoxy_setup_X.Y.Z.exe</tt>
+ $ gpg --armor --detach --sign <tt class="FILENAME">privoxy_X.Y.Z.zip</tt></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>
+ <p>and upload the files to SourceForge.</p>
+ <p>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"><i class="EMPHASIS">make sure that
- you have freshly exported the right version into an empty
- directory</i></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>
-
+ <h3 class="SECT3"><a name="NEWRELEASE-DEBIAN" id="NEWRELEASE-DEBIAN">6.3.7. Debian</a></h3>
+ <p>First, <span class="emphasis"><i class="EMPHASIS">make sure that you have freshly exported the right version
+ into an empty directory</i></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 border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- debchange -v 3.0.25-UNRELEASED-1 "New upstream version"
-</pre>
+ <pre class="PROGRAMLISTING"> debchange -v 3.0.27-stable-1 "New upstream version"</pre>
</td>
</tr>
</table>
-
<p>Then, run:</p>
-
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- dpkg-buildpackage -rfakeroot -us -uc -b
-</pre>
+ <pre class="PROGRAMLISTING"> dpkg-buildpackage -rfakeroot -us -uc -b</pre>
</td>
</tr>
</table>
-
- <p>This will create <tt class=
- "FILENAME">../privoxy_3.0.25-UNRELEASED-1_i386.deb</tt> which can be
- uploaded. To upload the package to Sourceforge, simply issue</p>
-
+ <p>This will create <tt class="FILENAME">../privoxy_3.0.27-stable-1_i386.deb</tt> which can be uploaded. To
+ upload the package to Sourceforge, simply issue</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- make debian-upload
-</pre>
+ <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"><i class="EMPHASIS">make sure that
- you have freshly exported the right version into an empty
- directory</i></span>. (See "Building and releasing packages"
- above).</p>
-
- <p>There are three modules available in the CVS repository for use on
- Mac OS X, though technically only two of them generate a release (the
- other can be used to install from source).</p>
-
+ <h3 class="SECT3"><a name="NEWRELEASE-MACOSX" id="NEWRELEASE-MACOSX">6.3.8. Mac OS X</a></h3>
+ <p>First, <span class="emphasis"><i class="EMPHASIS">make sure that you have freshly exported the right version
+ into an empty directory</i></span>. (See "Building and releasing packages" above).</p>
+ <p>There are three modules available in the Git repository for use on Mac OS X, though technically only two of
+ them generate a release (the other can be used to install from source).</p>
<div class="SECT4">
- <h4 class="SECT4"><a name="OS-X-OSXPACKAGEBUILDER-MODULE" id=
- "OS-X-OSXPACKAGEBUILDER-MODULE">6.3.8.1. OSXPackageBuilder
- module</a></h4>
-
- <p>The OSXPackageBuilder module generates OS X installer packages
- supporting all Macs running OS X 10.4 and above. Obtain it from CVS
- as follows into a folder parallel to the exported privoxy
- source:</p>
-
+ <h4 class="SECT4"><a name="OS-X-OSXPACKAGEBUILDER-MODULE" id="OS-X-OSXPACKAGEBUILDER-MODULE">6.3.8.1.
+ OSXPackageBuilder module</a></h4>
+ <p>The OSXPackageBuilder module generates OS X installer packages supporting all Macs running OS X 10.4 and
+ above. Obtain it from Git as follows into a folder parallel to the exported privoxy source:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
- cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co OSXPackageBuilder
-</pre>
+ cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co OSXPackageBuilder</pre>
</td>
</tr>
</table>
-
- <p>The module contains complete instructions on its usage in the
- file <tt class="FILENAME">OS X Package Builder HOWTO.txt</tt>.</p>
-
- <p>Once the package(s) have been generated, you can then upload
- them directly to the Files section of the Sourceforge project in
- the Macintosh (OS X) folder. Each new version release of Privoxy
- should have a new subfolder created in which to store its files.
- Please ensure that the folder contains a readme file that makes it
- clear which package is for whichversion of OS X.</p>
+ <p>The module contains complete instructions on its usage in the file <tt class="FILENAME">OS X Package
+ Builder HOWTO.txt</tt>.</p>
+ <p>Once the package(s) have been generated, you can then upload them directly to the Files section of the
+ Sourceforge project in the Macintosh (OS X) folder. Each new version release of Privoxy should have a new
+ subfolder created in which to store its files. Please ensure that the folder contains a readme file that
+ makes it clear which package is for whichversion of OS X.</p>
</div>
-
<div class="SECT4">
- <h4 class="SECT4"><a name="OS-X-OSXSETUP-MODULE" id=
- "OS-X-OSXSETUP-MODULE">6.3.8.2. osxsetup module
+ <h4 class="SECT4"><a name="OS-X-OSXSETUP-MODULE" id="OS-X-OSXSETUP-MODULE">6.3.8.2. osxsetup module
(DEPRECATED)</a></h4>
-
- <p><span class="emphasis"><i class="EMPHASIS">This module is
- deprecated since the installer it generates places all Privoxy
- files in one folder in a non-standard location, and supports only
- Intel Macs running OS X 10.6 or higher.</i></span></p>
-
- <p>Check out the module from CVS as follows into a folder parallel
- to the exported privoxy source:</p>
-
+ <p><span class="emphasis"><i class="EMPHASIS">This module is deprecated since the installer it generates
+ places all Privoxy files in one folder in a non-standard location, and supports only Intel Macs running OS X
+ 10.6 or higher.</i></span></p>
+ <p>Check out the module from Git as follows into a folder parallel to the exported privoxy source:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
- cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co osxsetup
-</pre>
+ cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co osxsetup</pre>
</td>
</tr>
</table>
-
<p>Then run:</p>
-
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- cd osxsetup
- build
-</pre>
+ <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>
-
+ <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 border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING">
- zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg
-</pre>
+ <pre class="PROGRAMLISTING"> zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg</pre>
</td>
</tr>
</table>
-
- <p>You can then upload this file directly to the Files section of
- the Sourceforge project in the Macintosh (OS X) folder. Each new
- version release of Privoxy should have a new subfolder created in
- which to store its files. Please ensure that the folder contains a
- readme file that makes it clear which version(s) of OS X the
+ <p>You can then upload this file directly to the Files section of the Sourceforge project in the Macintosh
+ (OS X) folder. Each new version release of Privoxy should have a new subfolder created in which to store its
+ files. Please ensure that the folder contains a readme file that makes it clear which version(s) of OS X the
package supports.</p>
</div>
-
<div class="SECT4">
- <h4 class="SECT4"><a name="OS-X-MACSETUP-MODULE" id=
- "OS-X-MACSETUP-MODULE">6.3.8.3. macsetup module</a></h4>
-
- <p>The macsetup module is ideal if you wish to build and install
- Privoxy from source on a single machine.</p>
-
- <p>Check out the module from CVS as follows into a folder parallel
- to the exported privoxy source:</p>
-
+ <h4 class="SECT4"><a name="OS-X-MACSETUP-MODULE" id="OS-X-MACSETUP-MODULE">6.3.8.3. macsetup module</a></h4>
+ <p>The macsetup module is ideal if you wish to build and install Privoxy from source on a single machine.</p>
+ <p>Check out the module from Git as follows into a folder parallel to the exported privoxy source:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
<pre class="PROGRAMLISTING">
- cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co macsetup
-</pre>
+ cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co macsetup</pre>
</td>
</tr>
</table>
-
- <p>The module contains complete instructions on its usage in its
- <tt class="FILENAME">README</tt> file. The end result will be the
- exported version of Privoxy installed on the build machine.</p>
+ <p>The module contains complete instructions on its usage in its <tt class="FILENAME">README</tt> file. The
+ end result will be the exported version of Privoxy installed on the build machine.</p>
</div>
</div>
-
<div class="SECT3">
- <h3 class="SECT3"><a name="NEWRELEASE-FREEBSD" id=
- "NEWRELEASE-FREEBSD">6.3.9. FreeBSD</a></h3>
-
- <p>Update the www/privoxy port and submit a diff upstream. For
- details see the <a href=
- "https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/"
- target="_top">FreeBSD Porter's Handbook</a>.</p>
+ <h3 class="SECT3"><a name="NEWRELEASE-FREEBSD" id="NEWRELEASE-FREEBSD">6.3.9. FreeBSD</a></h3>
+ <p>Update the www/privoxy port and submit a diff upstream. For details see the <a href=
+ "https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/" target="_top">FreeBSD Porter's
+ Handbook</a>.</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>
-
+ <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>
+ <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>
+ <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"><i class="EMPHASIS">3.0.25 (beta)</i></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>
+ <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"><i class="EMPHASIS">3.0.27 (beta)</i></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=
- "https://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>
+ <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:privoxy-announce@lists.privoxy.org" target="_top">announce mailing list</a>, Subject: "Version X.Y.Z
+ available for download". Be sure to include the <a href=
+ "https://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>
+ <p>Then update the source code for the next version to be released:</p>
+ <ul>
+ <li>
+ <p>Increment the version number and change the code status to "UNRELEASED" in <tt class=
+ "FILENAME">configure.in</tt></p>
+ </li>
+ <li>
+ <p>Rebuild configure (<span class="QUOTE">"<b class="COMMAND">autoheader && autoconf</b>"</span>) and
+ GNUMakefile (<span class="QUOTE">"<b class="COMMAND">./configure</b>"</span>)</p>
+ </li>
+ <li>
+ <p><span class="QUOTE">"<b class="COMMAND">make dok-release</b>"</span> to update the sgml documentation
+ source files.</p>
+ </li>
+ <li>
+ <p>Commit all your changes.</p>
+ </li>
+ </ul>
</div>
</div>
-
<div class="NAVFOOTER">
<hr align="left" width="100%">
-
- <table summary="Footer navigation table" width="100%" border="0"
- cellpadding="0" cellspacing="0">
+ <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>
+ <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>
projects / privoxy.git / blobdiff