+
+ * 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. config, the
+ man page (and the html version of the man page), and the PDF docs fall in
+ this category. REAMDE, the man page, AUTHORS, and config should all also be
+ committed to CVS for other packagers. The formal docs should be uploaded to
+ the webserver. See the Section "Updating the webserver" in this manual for
+ details.
+
+ * The User Manual 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 User Manual link from the
+ main page since we need to keep manuals for various versions available).
+ The CGI pages will link to something like http://privoxy.org/$(VERSION)/
+ user-manual/. 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.
+
+ * All developers should look at the ChangeLog and make sure noteworthy
+ changes are referenced.
+
+ * Commit all files that were changed in the above steps!
+
+ * Tag all files in CVS with the version number with "cvs tag v_X_Y_Z". Don't
+ use vX_Y_Z, ver_X_Y_Z, v_X.Y.Z (won't work) etc.
+
+ * If the release was in a development branch, increase the point version from
+ even to odd (X.Y.(Z+1)) again in configure.in and commit your change.
+
+ * On the webserver, copy the user manual to a new top-level directory called
+ X.Y.Z. 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 X.Y.(Z-1) to X.Y.Z and X.Y.
+ (Z+1) to . (i.e. dot).
+
+-------------------------------------------------------------------------------
+
+6.3. Building and Releasing the Packages
+
+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.
+
+For all types of packages, including the source tarball, you must make sure
+that you build from clean sources by exporting the right version from CVS into
+an empty directory (just press return when asked for a password):
+
+ 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
+
+
+Do NOT change 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.
+
++-----------------------------------------------------------------------------+
+| Warning |
+|-----------------------------------------------------------------------------|
+|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! |
++-----------------------------------------------------------------------------+
+
+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.
+
+-------------------------------------------------------------------------------
+
+6.3.1. Note on Privoxy Packaging
+
+Please keep these general guidelines in mind when putting together your
+package. These apply to all platforms!
+
+ * Privoxy requires write access to: all *.action files, all logfiles, and the
+ trust file. You will need to determine the best way to do this for your
+ platform.
+
+ * Please include up to date documentation. At a bare minimum:
+
+ LICENSE (top-level directory)
+
+ README (top-level directory)
+
+ AUTHORS (top-level directory)
+
+ man page (top-level directory, Unix-like platforms only)
+
+ The User Manual (doc/webserver/user-manual/)
+
+ FAQ (doc/webserver/faq/)
+
+ Also suggested: Developer Manual (doc/webserver/developer-manual) and
+ ChangeLog (top-level directory). FAQ and the manuals are HTML docs. There
+ are also text versions in doc/text/ which could conceivably also be
+ included.
+
+ The documentation has been designed such that the manuals are linked to
+ each other from parallel directories, and should be packaged that way.
+ privoxy-index.html can also be included and can serve as a focal point for
+ docs and other links of interest (and possibly renamed to index.html). 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 doc/webserver/man-page/privoxy-man-page.html, and should be included
+ along with the manuals. There is also a css stylesheets that can be
+ included for better presentation: p_doc.css. This should be in the same
+ directory with privoxy-index.html, (i.e. one level up from the manual
+ directories).
+
+ * user.action and user.filter are designed for local preferences. Make sure
+ these do not get overwritten! config should not be overwritten either. This
+ has especially important configuration data in it. trust should be left in
+ tact as well.
+
+ * Other configuration files (default.action, default.filter and
+ standard.action) 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.
+
+ * Please check platform specific notes in this doc, if you haven't done
+ "Privoxy" 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).
+
+ * Packagers should do a "clean" 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.
+