freeze so that nobody will interfere with last minute changes.</p>
</li>
<li>
- <p>Update the code status (CODE_STATUS="xxx") in configure.in to one of "alpha", "beta" or "stable".</p>
+ <p>Update the code status (CODE_STATUS="xxx") in <tt class="FILENAME">configure.in</tt> to one of "alpha",
+ "beta" or "stable".</p>
</li>
<li>
<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">$ autoheader && autoconf # rebuild configure
-$ ./configure # rebuild GNUmakefile</pre>
+ <pre class="PROGRAMLISTING"> $ autoheader && autoconf # rebuild configure
+ $ ./configure # rebuild GNUmakefile</pre>
</td>
</tr>
</table>
</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>
+ "for-privoxy-version=x.y.z" minimum version number in <tt class="FILENAME">default.action.master</tt> 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>
+ <pre class="PROGRAMLISTING"> {{settings}}
+ #############################################################################
+ #MASTER# COMMENT: The minimum Privoxy version:
+ for-privoxy-version=3.0.11</pre>
</td>
</tr>
</table>
<td>
<pre class="PROGRAMLISTING"> $ git tag
# to see the tags
- $ git log [last release tag]..HEAD > /tmp/log
+ $ git log [last release tag]..master > /tmp/log
# get the commit log since the last release
$ utils/makeChangeLog /tmp/log > /tmp/change.log
# reformat the commit log</pre>
<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>
+ <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>All developers should look at the <tt class="FILENAME">ChangeLog</tt> and make sure noteworthy changes are
referenced.</p>
</li>
+ <li>
+ <p>Update the announcement at <tt class="FILENAME">doc/webserver/announce.txt</tt>.</p>
+ </li>
<li>
<p>All documentation should be rebuilt:</p>
<table border="0" bgcolor="#E0E0E0" width="90%">
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">https://www.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>
+ This needs to be updated for each new release and is done with the <span class="QUOTE">"webserver"</span>
+ target.</p>
</li>
<li>
- <p>Tag all files in Git with the version number with <span class="QUOTE">"<b class="COMMAND">git tag
+ <p>Tag all files in Git with the version number with <span class="QUOTE">"<b class="COMMAND">git tag -s
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>Push the tag to the remote with <span class="QUOTE">"<b class="COMMAND">git push origin
+ v_X_Y_Z</b>"</span>.</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,
</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>
+ are HTML docs.</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
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>, <tt class=
+ "FILENAME">regression-tests.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=
<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>
+ into an empty directory</i></span>. (See "Building and releasing packages" above). Then run from that
+ directory:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> cd current
- autoheader && autoconf && ./configure</pre>
+ <pre class="PROGRAMLISTING"> autoheader && autoconf && ./configure</pre>
</td>
</tr>
</table>
</td>
</tr>
</table>
- <p>To upload the package to Sourceforge, simply issue</p>
+ </div>
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="NEWRELEASE-WINDOWS" id="NEWRELEASE-WINDOWS">6.3.3. 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>Check that you have the current versions of the <a href=
+ "https://sourceforge.net/projects/nsis/files/NSIS%203/" target="_top">NSIS installer</a>, <a href=
+ "https://ftp.pcre.org/pub/pcre/" target="_top">PCRE library</a>, <a href="https://tls.mbed.org/download"
+ target="_top">MBED TLS library</a>, <a href="https://github.com/google/brotli/releases" target="_top">Brotli
+ library</a>, and that the <span class="emphasis"><i class="EMPHASIS">MAKENSIS</i></span> evar in <tt class=
+ "FILENAME">windows/GNUMakefile</tt> points to the NSIS installer program. (See the <a href=
+ "../user-manual/installation.html#WINBUILD-CYGWIN" target="_top"><span class="emphasis"><i class=
+ "EMPHASIS">Building from Source / Windows</i></span></a> section of the User Manual for details.)</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"> cd windows
+ 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 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"> make tarball-upload</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>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>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-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/projects/ijbswa/files/" 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>
+ <h3 class="SECT3"><a name="NEWRELEASE-DEBIAN" id="NEWRELEASE-DEBIAN">6.3.4. Debian</a></h3>
+ <p>Using git-buildpackage we start with a clone of the last Debian version:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> cd current
- autoheader && autoconf && ./configure</pre>
+ <pre class="PROGRAMLISTING"> gbp clone https://salsa.debian.org/debian/privoxy.git
+ cd privoxy</pre>
</td>
</tr>
</table>
- <p>Then do</p>
+ <p>or if the repository is already there</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"> cd privoxy
+ gbp pull</pre>
</td>
</tr>
</table>
- <p>To upload the package to Sourceforge, simply issue</p>
+ <p>Now import the newly released upstream tarball via debian/watch file:</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"> gbp import-orig --uscan</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-SOLARIS" id="NEWRELEASE-SOLARIS">6.3.4. Solaris</a></h3>
- <p>Login to Sourceforge's compilefarm via ssh:</p>
+ <p>Next update all Debian quilt patches to the new version:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> ssh cf.sourceforge.net</pre>
+ <pre class="PROGRAMLISTING"> while quilt push; do quilt refresh; done</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>If some patch is no longer required (because it is already merged upstream), it can be removed using</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> cd current
- autoheader && autoconf && ./configure</pre>
+ <pre class="PROGRAMLISTING"> quilt delete XX_patchname.patch
+ git rm debian/patches/XX_patchname.patch</pre>
</td>
</tr>
</table>
- <p>Then run</p>
+ <p>If the patch needs modification, you can apply, edit and update it with</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> gmake solaris-dist</pre>
+ <pre class="PROGRAMLISTING"> quilt push -f
+ quilt edit some_file
+ quilt refresh</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.5. 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>
+ <p>until</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> cd windows
- make</pre>
+ <pre class="PROGRAMLISTING"> while quilt push; do quilt refresh; done</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 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>
+ <p>succeeds. Then you can</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <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>
+ <pre class="PROGRAMLISTING"> quilt pop -a</pre>
</td>
</tr>
</table>
- <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.6. 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>
+ <p>Now add a new entry to the debian/changelog representing the new version:</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> debchange -v 3.0.30-UNRELEASED-1 "New upstream version"</pre>
+ <pre class="PROGRAMLISTING"> dch -v 3.0.34-1</pre>
</td>
</tr>
</table>
- <p>Then, run:</p>
+ <p>and describe what you did before and don't forget to git commit all changes.</p>
+ <p>Now you can build the package on the local machine using</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> dpkg-buildpackage -rfakeroot -us -uc -b</pre>
+ <pre class="PROGRAMLISTING"> gbp buildpackage -us -uc</pre>
</td>
</tr>
</table>
- <p>This will create <tt class="FILENAME">../privoxy_3.0.30-UNRELEASED-1_i386.deb</tt> which can be uploaded. To
- upload the package to Sourceforge, simply issue</p>
+ <p>You should check for warnings using</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> make debian-upload</pre>
+ <pre class="PROGRAMLISTING"> lintian -iI ../build-area/privoxy_3.0.34-1_amd64.changes</pre>
</td>
</tr>
</table>
- </div>
- <div class="SECT3">
- <h3 class="SECT3"><a name="NEWRELEASE-MACOSX" id="NEWRELEASE-MACOSX">6.3.7. 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 backups 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>
+ <p>Maybe rebuild the package in different defined cowbuilder environments like</p>
+ <table border="0" bgcolor="#E0E0E0" width="100%">
+ <tr>
+ <td>
+ <pre class=
+ "PROGRAMLISTING"> sudo cowbuilder --build --basepath /var/cache/pbuilder/base.cow ../build-area/privoxy_3.0.34-1.dsc</pre>
+ </td>
+ </tr>
+ </table>
+ <p>And try to run autopackage testing suite on the result:</p>
+ <table border="0" bgcolor="#E0E0E0" width="100%">
+ <tr>
+ <td>
+ <pre class=
+ "PROGRAMLISTING"> autopkgtest /var/cache/pbuilder/result/privoxy_3.0.34-1_amd64.changes -s -- schroot sid</pre>
+ </td>
+ </tr>
+ </table>
+ <p>Or just push the changes to salsa.debian.org, where a CI pipeline is defined for the package, that builds
+ and tests it.</p>
+ <p>If everything is okay, run cowbuilder with i386 and amd64 environments for current Debian stable release and
+ build privoxy_3.0.34-1_i386.deb and privoxy_3.0.34-1_amd64.deb. Then sign both files:</p>
+ <table border="0" bgcolor="#E0E0E0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING"> gpg --detach-sign --armor privoxy_3.0.34-1_i386.deb
+ gpg --detach-sign --armor privoxy_3.0.34-1_amd64.deb</pre>
+ </td>
+ </tr>
+ </table>
+ <p>Create a README file containing the recent block from debian/changelog and upload the two packages, the two
+ signatures and the README to a freshly created folder below
+ https://sourceforge.net/projects/ijbswa/files/Debian/</p>
<div class="SECT4">
- <h4 class="SECT4"><a name="OS-X-OSXPACKAGEBUILDER-MODULE" id="OS-X-OSXPACKAGEBUILDER-MODULE">6.3.7.1.
- OSXPackageBuilder module (Documentation out of date)</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="SNAPSHOT-DEBIAN" id="SNAPSHOT-DEBIAN">6.3.4.1. Debian GIT Snapshot</a></h4>
+ <p>For building just a git snapshot build the following workflow may be useful. First create a build
+ environment, for this you may have to run the following commands:</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>
+ <pre class="PROGRAMLISTING"> sudo apt install build-essential devscripts
+ sudo apt-get build-dep privoxy</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.7.2. osxsetup module
- (DEPRECATED) (Documentation out of date)</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>After this enter the checked out privoxy git tree and check that all (new) build dependencies are met:</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>
+ <pre class="PROGRAMLISTING"> dpkg-checkbuilddeps</pre>
</td>
</tr>
</table>
- <p>Then run:</p>
+ <p>If something is missing, just add it using</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
- <pre class="PROGRAMLISTING"> cd osxsetup
- build</pre>
+ <pre class="PROGRAMLISTING"> sudo apt install foobar</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>Now you may update debian/changelog, especially the version number using</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"> dch</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.7.3. macsetup module
- (Documentation out of date)</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>
+ <p>and finally build the package:</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>
+ <pre class="PROGRAMLISTING"> debuild -us -uc -b</pre>
+ </td>
+ </tr>
+ </table>
+ <p>If everything went okay, you may find the resulting Debian package in the parent directory.</p>
+ <p>You may want to clean up the build tree using</p>
+ <table border="0" bgcolor="#E0E0E0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING"> debian/rules clean</pre>
+ </td>
+ </tr>
+ </table>
+ <p>And maybe repair some artefacts using one or both of the following commands:</p>
+ <table border="0" bgcolor="#E0E0E0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING"> git reset --hard
+ git clean -fd</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.8. FreeBSD</a></h3>
+ <h3 class="SECT3"><a name="NEWRELEASE-MACOSX" id="NEWRELEASE-MACOSX">6.3.5. macOS / 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>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"> git clone ssh://git@git.privoxy.org:23/git/OSXPackageBuilder.git</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 which version of OS X.</p>
+ </div>
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="NEWRELEASE-FREEBSD" id="NEWRELEASE-FREEBSD">6.3.6. 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 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.30 (beta)</i></span>.</p>
+ <p>After the package is ready, it is time to upload it and go through the release steps. The upload is done at
+ <a href="https://sourceforge.net/projects/ijbswa/upload/" target="_top">SourceForge</a> after logging in.</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
<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/projects/ijbswa/files/" target=
+ "mailto:privoxy-announce@lists.privoxy.org" target="_top">announce mailing list</a>, Subject: "Announcing Privoxy
+
X.Y.Z $CODE_STATUS". Be sure to include the <a href="https://sourceforge.net/projects/ijbswa/files/" 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>
projects / privoxy.git / blobdiff