-<!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">
- <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=utf-8">
-</head>
-<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">
- <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 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,
- 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"><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>
- </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>
- <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> and update the code status (CODE_STATUS="xxx") to one of "alpha", "beta" or
- "stable". Rebuild configure and GNUMakefile to make sure the updated values are being used.</p>
- </li>
- <li>
- <p>Use the dok-release target 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}}
+<!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"><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=ISO-8859-1"></HEAD
+><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"
+><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
+ALIGN="LEFT"
+WIDTH="100%"></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="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"
+>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
+><P
+></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"
+><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
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="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
+><P
+></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
+> and update the code
+ status (CODE_STATUS="xxx") to one of "alpha", "beta" or "stable".
+ Rebuild configure and GNUMakefile to make sure the updated values are
+ being used.
+ </P
+></LI
+><LI
+><P
+> Use the dok-release target 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>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.
- README, 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"><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>
- </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"><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>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
- <pre class="PROGRAMLISTING"> mkdir dist # delete or choose different name if it already exists
+for-privoxy-version=3.0.11</PRE
+></TD
+></TR
+></TABLE
+></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. README, 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"
+><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
+></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"
+>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
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+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"><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>
- <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>
- </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"><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>
- </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"><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>
- </td>
- </tr>
- </table>
- <p>Then do:</p>
- <table border="0" bgcolor="#E0E0E0" 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 border="0" bgcolor="#E0E0E0" 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"><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>
- <p>Then run:</p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
- <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>
- </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>
- </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>
- </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>
- <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>
- </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 border="0" bgcolor="#E0E0E0" 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 border="0" bgcolor="#E0E0E0" 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 border="0" bgcolor="#E0E0E0" 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 border="0" bgcolor="#E0E0E0" 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"><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>
- </td>
- </tr>
- </table>
- <p>Then run</p>
- <table border="0" bgcolor="#E0E0E0" 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>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>
- <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>
- </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 border="0" bgcolor="#E0E0E0" 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"><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.27-UNRELEASED-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>
- </td>
- </tr>
- </table>
- <p>This will create <tt class="FILENAME">../privoxy_3.0.27-UNRELEASED-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>
- </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>
- <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>
- <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>
- </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>
- </div>
- <div class="SECT4">
- <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>
- <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>
- </td>
- </tr>
- </table>
- <p>Then run:</p>
- <table border="0" bgcolor="#E0E0E0" 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 border="0" bgcolor="#E0E0E0" 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 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>
- <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>
- </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>
- </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>
- </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"><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: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>
- </div>
- </div>
- <div class="NAVFOOTER">
- <hr align="left" 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>
+ 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
+><DIV
+CLASS="WARNING"
+><P
+></P
+><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
+></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"
+>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
+><P
+></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
+></LI
+><LI
+><P
+> Please include up to date documentation. At a bare minimum:
+ </P
+><P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+> <TT
+CLASS="FILENAME"
+>LICENSE</TT
+> (top-level directory)
+ </TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+><P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+> <TT
+CLASS="FILENAME"
+>README</TT
+> (top-level directory)
+ </TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+><P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+> <TT
+CLASS="FILENAME"
+>AUTHORS</TT
+> (top-level directory)
+ </TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+><P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+> <TT
+CLASS="FILENAME"
+>man page</TT
+> (top-level directory, Unix-like
+ platforms only)
+ </TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+><P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+> <TT
+CLASS="FILENAME"
+>The User Manual</TT
+> (doc/webserver/user-manual/)
+ </TD
+></TR
+></TBODY
+></TABLE
+><P
+></P
+><P
+></P
+><TABLE
+BORDER="0"
+><TBODY
+><TR
+><TD
+> <TT
+CLASS="FILENAME"
+>FAQ</TT
+> (doc/webserver/faq/)
+ </TD
+></TR
+></TBODY
+></TABLE
+><P
+></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 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"
+>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
+></TD
+></TR
+></TABLE
+><P
+> Then do:
+ </P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+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
+BORDER="0"
+BGCOLOR="#E0E0E0"
+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"
+>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
+><P
+> Then run:
+ </P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><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
+></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
+></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
+></DIV
+><DIV
+CLASS="SECT3"
+><H3
+CLASS="SECT3"
+><A
+NAME="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
+></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
+BORDER="0"
+BGCOLOR="#E0E0E0"
+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
+BORDER="0"
+BGCOLOR="#E0E0E0"
+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
+BORDER="0"
+BGCOLOR="#E0E0E0"
+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"
+>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
+></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
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+WIDTH="100%"
+><TR
+><TD
+><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
+></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"
+>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
+><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
+></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
+BORDER="0"
+BGCOLOR="#E0E0E0"
+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"
+>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.27-UNRELEASED-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
+></TD
+></TR
+></TABLE
+><P
+> This will create
+ <TT
+CLASS="FILENAME"
+>../privoxy_3.0.27-UNRELEASED-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
+></TD
+></TR
+></TABLE
+></DIV
+><DIV
+CLASS="SECT3"
+><H3
+CLASS="SECT3"
+><A
+NAME="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
+><DIV
+CLASS="SECT4"
+><H4
+CLASS="SECT4"
+><A
+NAME="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
+><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
+></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
+></DIV
+><DIV
+CLASS="SECT4"
+><H4
+CLASS="SECT4"
+><A
+NAME="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
+><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
+></TD
+></TR
+></TABLE
+><P
+> Then run:
+ </P
+><TABLE
+BORDER="0"
+BGCOLOR="#E0E0E0"
+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
+BORDER="0"
+BGCOLOR="#E0E0E0"
+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 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"
+>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
+><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
+></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
+></DIV
+></DIV
+><DIV
+CLASS="SECT3"
+><H3
+CLASS="SECT3"
+><A
+NAME="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"
+>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
+><P
+></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"
+><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"
+>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
+></DIV
+></DIV
+><DIV
+CLASS="NAVFOOTER"
+><HR
+ALIGN="LEFT"
+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
+>
\ No newline at end of file
projects / privoxy.git / blobdiff