-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
-Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
+"http://www.w3.org/TR/html4/loose.dtd">
+
<html>
- <head>
- <meta name="generator" content="HTML Tidy, see www.w3.org">
- <title>
- Releasing a New Version
- </title>
- <meta name="GENERATOR" content=
- "Modular DocBook HTML Stylesheet Version 1.79">
- <link rel="HOME" title="Privoxy Developer Manual" href="index.html">
- <link rel="PREVIOUS" title="Testing Guidelines" href="testing.html">
- <link rel="NEXT" title="Update the Webserver" href=
- "webserver-update.html">
- <link rel="STYLESHEET" type="text/css" href="../p_doc.css">
- <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
-<style type="text/css">
- body {
+<head>
+ <meta name="generator" content=
+ "HTML Tidy for Linux/x86 (vers 7 December 2008), see www.w3.org">
+
+ <title>Releasing a New Version</title>
+ <meta name="GENERATOR" content=
+ "Modular DocBook HTML Stylesheet Version 1.79">
+ <link rel="HOME" title="Privoxy Developer Manual" href="index.html">
+ <link rel="PREVIOUS" title="Testing Guidelines" href="testing.html">
+ <link rel="NEXT" title="Update the Webserver" href="webserver-update.html">
+ <link rel="STYLESHEET" type="text/css" href="../p_doc.css">
+ <meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
+ <style type="text/css">
+body {
background-color: #EEEEEE;
color: #000000;
- }
- :link { color: #0000FF }
- :visited { color: #840084 }
- :active { color: #0000FF }
- hr.c1 {text-align: left}
-</style>
- </head>
- <body class="SECT1">
- <div class="NAVHEADER">
- <table summary="Header navigation table" width="100%" border="0"
- cellpadding="0" cellspacing="0">
- <tr>
- <th colspan="3" align="center">
- Privoxy Developer Manual
- </th>
- </tr>
+ }
+ :link { color: #0000FF }
+ :visited { color: #840084 }
+ :active { color: #0000FF }
+ tt.c5 {font-style: italic}
+ td.c4 {font-weight: bold}
+ table.c3 {background-color: #E0E0E0}
+ span.c2 {font-style: italic}
+ hr.c1 {text-align: left}
+ </style>
+</head>
+
+<body class="SECT1">
+ <div class="NAVHEADER">
+ <table summary="Header navigation table" width="100%" border="0"
+ cellpadding="0" cellspacing="0">
+ <tr>
+ <th colspan="3" align="center">Privoxy Developer Manual</th>
+ </tr>
+
+ <tr>
+ <td width="10%" align="left" valign="bottom"><a href="testing.html"
+ accesskey="P">Prev</a></td>
+
+ <td width="80%" align="center" valign="bottom"></td>
+
+ <td width="10%" align="right" valign="bottom"><a href=
+ "webserver-update.html" accesskey="N">Next</a></td>
+ </tr>
+ </table>
+ <hr class="c1" width="100%">
+ </div>
+
+ <div class="SECT1">
+ <h1 class="SECT1"><a name="NEWRELEASE" id="NEWRELEASE">6. Releasing a New
+ Version</a></h1>
+
+ <p>When we release versions of <span class="APPLICATION">Privoxy</span>,
+ our work leaves our cozy secret lab and has to work in the cold
+ RealWorld[tm]. Once it is released, there is no way to call it back, so
+ it is very important that great care is taken to ensure that everything
+ runs fine, and not to introduce problems in the very last minute.</p>
+
+ <p>So when releasing a new version, please adhere exactly to the
+ procedure outlined in this chapter.</p>
+
+ <p>The following programs are required to follow this process: <tt class=
+ "FILENAME">ncftpput</tt> (ncftp), <tt class="FILENAME">scp, ssh</tt>
+ (ssh), <tt class="FILENAME">gmake</tt> (GNU's version of make), autoconf,
+ cvs.</p>
+
+ <div class="SECT2">
+ <h2 class="SECT2"><a name="VERSIONNUMBERS" id="VERSIONNUMBERS">6.1.
+ Version numbers</a></h2>
+
+ <p>First you need to determine which version number the release will
+ have. <span class="APPLICATION">Privoxy</span> version numbers consist
+ of three numbers, separated by dots, like in X.Y.Z (e.g. 3.0.0),
+ where:</p>
+
+ <ul>
+ <li>
+ <p>X, the version major, is rarely ever changed. It is increased by
+ one if turning a development branch into stable substantially
+ changes the functionality, user interface or configuration syntax.
+ Majors 1 and 2 were <span class="APPLICATION">Junkbuster</span>,
+ and 3 will be the first stable <span class=
+ "APPLICATION">Privoxy</span> release.</p>
+ </li>
+
+ <li>
+ <p>Y, the version minor, represents the branch within the major
+ version. At any point in time, there are two branches being
+ maintained: The stable branch, with an even minor, say, 2N, in
+ which no functionality is being added and only bug-fixes are made,
+ and 2N+1, the development branch, in which the further development
+ of <span class="APPLICATION">Privoxy</span> takes place. This
+ enables us to turn the code upside down and inside out, while at
+ the same time providing and maintaining a stable version. The minor
+ is reset to zero (and one) when the major is incremented. When a
+ development branch has matured to the point where it can be turned
+ into stable, the old stable branch 2N is given up (i.e. no longer
+ maintained), the former development branch 2N+1 becomes the new
+ stable branch 2N+2, and a new development branch 2N+3 is
+ opened.</p>
+ </li>
+
+ <li>
+ <p>Z, the point or sub version, represents a release of the
+ software within a branch. It is therefore incremented immediately
+ before each code freeze. In development branches, only the even
+ point versions correspond to actual releases, while the odd ones
+ denote the evolving state of the sources on CVS in between. It
+ follows that Z is odd on CVS in development branches most of the
+ time. There, it gets increased to an even number immediately before
+ a code freeze, and is increased to an odd number again immediately
+ thereafter. This ensures that builds from CVS snapshots are easily
+ distinguished from released versions. The point version is reset to
+ zero when the minor changes.</p>
+
+ <p>Stable branches work a little differently, since there should be
+ little to no development happening in such branches. Remember, only
+ bugfixes, which presumably should have had some testing before
+ being committed. Stable branches will then have their version
+ reported as <tt class="LITERAL">0.0.0</tt>, during that period
+ between releases when changes are being added. This is to denote
+ that this code is <span class="emphasis EMPHASIS c2">not for
+ release</span>. Then as the release nears, the version is bumped
+ according: e.g. <tt class="LITERAL">3.0.1 -> 0.0.0 ->
+ 3.0.2</tt>.</p>
+ </li>
+ </ul>
+
+ <p>In summary, the main CVS trunk is the development branch where new
+ features are being worked on for the next stable series. This should
+ almost always be where the most activity takes place. There is always
+ at least one stable branch from the trunk, e.g now it is <tt class=
+ "LITERAL">3.0</tt>, which is only used to release stable versions. Once
+ the initial *.0 release of the stable branch has been done, then as a
+ rule, only bugfixes that have had prior testing should be committed to
+ the stable branch. Once there are enough bugfixes to justify a new
+ release, the version of this branch is again incremented Example: 3.0.0
+ -> 3.0.1 -> 3.0.2, etc are all stable releases from within the
+ stable branch. 3.1.x is currently the main trunk, and where work on
+ 3.2.x is taking place. If any questions, please post to the devel list
+ <span class="emphasis EMPHASIS c2">before</span> committing to a stable
+ branch!</p>
+
+ <p>Developers should remember too that if they commit a bugfix to the
+ stable branch, this will more than likely require a separate submission
+ to the main trunk, since these are separate development trees within
+ CVS. If you are working on both, then this would require at least two
+ separate check outs (i.e main trunk, <span class=
+ "emphasis EMPHASIS c2">and</span> the stable release branch, which is
+ <tt class="LITERAL">v_3_0_branch</tt> at the moment).</p>
+ </div>
+
+ <div class="SECT2">
+ <h2 class="SECT2"><a name="BEFORERELEASE" id="BEFORERELEASE">6.2.
+ Before the Release: Freeze</a></h2>
+
+ <p>The following <span class="emphasis EMPHASIS c2">must be done by one
+ of the developers</span> prior to each new release.</p>
+
+ <ul>
+ <li>
+ <p>Make sure that everybody who has worked on the code in the last
+ couple of days has had a chance to yell <span class=
+ "QUOTE">"no!"</span> in case they have pending changes/fixes in
+ their pipelines. Announce the freeze so that nobody will interfere
+ with last minute changes.</p>
+ </li>
+
+ <li>
+ <p>Increment the version number (point from odd to even in
+ development branches!) in <tt class="FILENAME">configure.in</tt>.
+ (RPM spec files will need to be incremented as well.)</p>
+ </li>
+
+ <li>
+ <p>If <tt class="FILENAME">default.action</tt> has changed since
+ last release (i.e. software release or standalone actions file
+ release), bump up its version info to A.B in this line:</p>
+
+ <table class="c3" border="0" width="90%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
+ {+add-header{X-Actions-File-Version: A.B} -filter -no-popups}
+</pre>
+ </td>
+ </tr>
+ </table>
+
+ <p>Then change the version info in doc/webserver/actions/index.php,
+ line: '$required_actions_file_version = "A.B";'</p>
+ </li>
+
+ <li>
+ <p>All documentation should be rebuild after the version bump.
+ Finished docs should be then be committed to CVS (for those without
+ the ability to build these). Some docs may require rather obscure
+ processing tools. <tt class="FILENAME">config</tt>, the man page
+ (and the html version of the man page), and the PDF docs fall in
+ this category. REAMDE, the man page, AUTHORS, and config should all
+ also be committed to CVS for other packagers. The formal docs
+ should be uploaded to the webserver. See the Section "Updating the
+ webserver" in this manual for details.</p>
+ </li>
+
+ <li>
+ <p>The <i class="CITETITLE">User Manual</i> is also used for
+ context sensitive help for the CGI editor. This is version
+ sensitive, so that the user will get appropriate help for his/her
+ release. So with each release a fresh version should be uploaded to
+ the webserver (this is in addition to the main <i class=
+ "CITETITLE">User Manual</i> link from the main page since we need
+ to keep manuals for various versions available). The CGI pages will
+ link to something like <tt class=
+ "LITERAL">http://privoxy.org/$(VERSION)/user-manual/</tt>. This
+ will need to be updated for each new release. There is no Makefile
+ target for this at this time!!! It needs to be done manually.</p>
+ </li>
+
+ <li>
+ <p>All developers should look at the <tt class=
+ "FILENAME">ChangeLog</tt> and make sure noteworthy changes are
+ referenced.</p>
+ </li>
+
+ <li>
+ <p><span class="emphasis EMPHASIS c2">Commit all files that were
+ changed in the above steps!</span></p>
+ </li>
+
+ <li>
+ <p>Tag all files in CVS with the version number with <span class=
+ "QUOTE">"<b class="COMMAND">cvs tag v_X_Y_Z</b>"</span>. Don't use
+ vX_Y_Z, ver_X_Y_Z, v_X.Y.Z (won't work) etc.</p>
+ </li>
+
+ <li>
+ <p>If the release was in a development branch, increase the point
+ version from even to odd (X.Y.(Z+1)) again in <tt class=
+ "FILENAME">configure.in</tt> and commit your change.</p>
+ </li>
+
+ <li>
+ <p>On the webserver, copy the user manual to a new top-level
+ directory called <tt class="FILENAME">X.Y.Z</tt>. This ensures that
+ help links from the CGI pages, which have the version as a prefix,
+ will go into the right version of the manual. If this is a
+ development branch release, also symlink <tt class=
+ "FILENAME">X.Y.(Z-1)</tt> to <tt class="FILENAME">X.Y.Z</tt> and
+ <tt class="FILENAME">X.Y.(Z+1)</tt> to <tt class="FILENAME">.</tt>
+ (i.e. dot).</p>
+ </li>
+ </ul>
+ </div>
+
+ <div class="SECT2">
+ <h2 class="SECT2"><a name="THERELEASE" id="THERELEASE">6.3. Building
+ and Releasing the Packages</a></h2>
+
+ <p>Now the individual packages can be built and released. Note that for
+ GPL reasons the first package to be released is always the source
+ tarball.</p>
+
+ <p>For <span class="emphasis EMPHASIS c2">all</span> types of packages,
+ including the source tarball, <span class="emphasis EMPHASIS c2">you
+ must make sure that you build from clean sources by exporting the right
+ version from CVS into an empty directory</span> (just press return when
+ asked for a password):</p>
+
+ <table class="c3" border="0" width="100%">
<tr>
- <td 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>
+ <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>
- <hr width="100%" class="c1">
- </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>
- <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>
+ <p><span class="emphasis EMPHASIS c2">Do NOT change</span> a single
+ bit, including, but not limited to version information after export
+ from CVS. This is to make sure that all release packages, and with
+ them, all future bug reports, are based on exactly the same code.</p>
+
+ <div class="WARNING">
+ <table class="WARNING" border="1" width="100%">
+ <tr>
+ <td class="c4" align="center">Warning</td>
+ </tr>
+
+ <tr>
+ <td align="left">
+ <p>Every significant release of Privoxy has included at least
+ one package that either had incorrect versions of files,
+ missing files, or incidental leftovers from a previous build
+ process that gave unknown numbers of users headaches to try to
+ figure out what was wrong. PLEASE, make sure you are using
+ pristene sources, and are following the prescribed process!</p>
+ </td>
+ </tr>
+ </table>
</div>
- <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>
+
+ <p>Please find additional instructions for the source tarball and the
+ individual platform dependent binary packages below. And details on the
+ Sourceforge release process below that.</p>
+
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="PACK-GUIDELINES" id=
+ "PACK-GUIDELINES">6.3.1. Note on Privoxy Packaging</a></h3>
+
+ <p>Please keep these general guidelines in mind when putting together
+ your package. These apply to <span class=
+ "emphasis EMPHASIS c2">all</span> platforms!</p>
+
<ul>
<li>
- <p>
- Make sure that everybody who has worked on the code in the last
- couple of days has had a chance to yell <span class=
- "QUOTE">"no!"</span> in case they have pending changes/fixes in
- their pipelines. Announce the freeze so that nobody will
- interfere with last minute changes.
- </p>
- </li>
- <li>
- <p>
- Increment the version number (point from odd to even in
- development branches!) in <tt class=
- "FILENAME">configure.in</tt>. (RPM spec files will need to be
- incremented as well.)
- </p>
+ <p><span class="APPLICATION">Privoxy</span> <span class=
+ "emphasis EMPHASIS c2">requires</span> write access to: all
+ <tt class="FILENAME">*.action</tt> files, all logfiles, and the
+ <tt class="FILENAME">trust</tt> file. You will need to determine
+ the best way to do this for your platform.</p>
</li>
+
<li>
- <p>
- If <tt class="FILENAME">default.action</tt> has changed since
- last release (i.e. software release or standalone actions file
- release), bump up its version info to A.B in this line:
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="90%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
- {+add-header{X-Actions-File-Version: A.B} -filter -no-popups}
-</pre>
- </td>
- </tr>
+ <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>
- <p>
- Then change the version info in
- doc/webserver/actions/index.php, line:
- '$required_actions_file_version = "A.B";'
- </p>
- </li>
- <li>
- <p>
- All documentation should be rebuild after the version bump.
- Finished docs should be then be committed to CVS (for those
- without the ability to build these). Some docs may require
- rather obscure processing tools. <tt class=
- "FILENAME">config</tt>, the man page (and the html version of
- the man page), and the PDF docs fall in this category. REAMDE,
- the man page, AUTHORS, and config should all also be committed
- to CVS for other packagers. The formal docs should be uploaded
- to the webserver. See the Section "Updating the webserver" in
- this manual for details.
- </p>
- </li>
- <li>
- <p>
- The <i class="CITETITLE">User Manual</i> is also used for
- context sensitive help for the CGI editor. This is version
- sensitive, so that the user will get appropriate help for
- his/her release. So with each release a fresh version should be
- uploaded to the webserver (this is in addition to the main <i
- class="CITETITLE">User Manual</i> link from the main page since
- we need to keep manuals for various versions available). The
- CGI pages will link to something like <tt class=
- "LITERAL">http://privoxy.org/$(VERSION)/user-manual/</tt>. This
- will need to be updated for each new release. There is no
- Makefile target for this at this time!!! It needs to be done
- manually.
- </p>
- </li>
- <li>
- <p>
- All developers should look at the <tt class=
- "FILENAME">ChangeLog</tt> and make sure noteworthy changes are
- referenced.
- </p>
+ <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>
- <span class="emphasis"><i class="EMPHASIS">Commit all files
- that were changed in the above steps!</i></span>
- </p>
+ <p><tt class="FILENAME">user.action</tt> and <tt class=
+ "FILENAME">user.filter</tt> are designed for local preferences.
+ Make sure these do not get overwritten! <tt class=
+ "FILENAME">config</tt> should not be overwritten either. This has
+ especially important configuration data in it. <tt class=
+ "FILENAME">trust</tt> should be left in tact as well.</p>
</li>
+
<li>
- <p>
- Tag all files in CVS with the version number with <span class=
- "QUOTE">"<b class="COMMAND">cvs tag v_X_Y_Z</b>"</span>. Don't
- use vX_Y_Z, ver_X_Y_Z, v_X.Y.Z (won't work) etc.
- </p>
+ <p>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>
- If the release was in a development branch, increase the point
- version from even to odd (X.Y.(Z+1)) again in <tt class=
- "FILENAME">configure.in</tt> and commit your change.
- </p>
+ <p>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>
- On the webserver, copy the user manual to a new top-level
- directory called <tt class="FILENAME">X.Y.Z</tt>. This ensures
- that help links from the CGI pages, which have the version as a
- prefix, will go into the right version of the manual. If this
- is a development branch release, also symlink <tt class=
- "FILENAME">X.Y.(Z-1)</tt> to <tt class="FILENAME">X.Y.Z</tt>
- and <tt class="FILENAME">X.Y.(Z+1)</tt> to <tt class=
- "FILENAME">.</tt> (i.e. dot).
- </p>
+ <p>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="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>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
+
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="NEWRELEASE-TARBALL" id=
+ "NEWRELEASE-TARBALL">6.3.2. Source Tarball</a></h3>
+
+ <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
+ freshly exported the right version into an empty directory</span>.
+ (See "Building and releasing packages" above). Then run:</p>
+
+ <table class="c3" border="0" width="100%">
<tr>
<td>
-<pre class="PROGRAMLISTING">
- 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 class="PROGRAMLISTING">
+ cd current
+ autoheader && autoconf && ./configure
</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">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>
- <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">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>
- <p>
- </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>
- <p>
- Then do:
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
make tarball-dist
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- To upload the package to Sourceforge, simply issue
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>To upload the package to Sourceforge, simply issue</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
make tarball-upload
</pre>
- </td>
- </tr>
- </table>
+ </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=
- "http://sourceforge.net/project/showfiles.php?group_id=11118"
- target="_top">file list</a> if unsure. Else, it must be set to
- the highest already available RPM release number for that version
- plus one.
- </p>
- <p>
- Then run:
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>Go to the displayed URL and release the file publicly on
+ Sourceforge. For the change log field, use the relevant section of
+ the <tt class="FILENAME">ChangeLog</tt> file.</p>
+ </div>
+
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="NEWRELEASE-RPM" id="NEWRELEASE-RPM">6.3.3.
+ SuSE, Conectiva or Red Hat RPM</a></h3>
+
+ <p>In following text, replace <tt class="REPLACEABLE c5">dist</tt>
+ with either <span class="QUOTE">"rh"</span> for Red Hat or
+ <span class="QUOTE">"suse"</span> for SuSE.</p>
+
+ <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
+ freshly exported the right version into an empty directory</span>.
+ (See "Building and releasing packages" above).</p>
+
+ <p>As the only exception to not changing anything after export from
+ CVS, now examine the file <tt class=
+ "FILENAME">privoxy-</tt><tt class="REPLACEABLE c5">dist</tt><tt class="FILENAME">.spec</tt>
+ and make sure that the version information and the RPM release number
+ are correct. The RPM release numbers for each version start at one.
+ Hence it must be reset to one if this is the first RPM for <tt class=
+ "REPLACEABLE c5">dist</tt> which is built from version X.Y.Z. Check
+ the <a href=
+ "http://sourceforge.net/project/showfiles.php?group_id=11118" target=
+ "_top">file list</a> if unsure. Else, it must be set to the highest
+ already available RPM release number for that version plus one.</p>
+
+ <p>Then run:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
cd current
autoheader && autoconf && ./configure
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- Then do
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
- make <tt class="REPLACEABLE"><i>dist</i></tt>-dist
+ <p>Then do</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
+ make <tt class="REPLACEABLE c5">dist</tt>-dist
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- To upload the package to Sourceforge, simply issue
- </p>
- <p>
- </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>
+ <p>To upload the package to Sourceforge, simply issue</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
+ make <tt class="REPLACEABLE c5">dist</tt>-upload <tt class=
+"REPLACEABLE c5">rpm_packagerev</tt>
</pre>
- </td>
- </tr>
- </table>
+ </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>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>where <tt class="REPLACEABLE c5">rpm_packagerev</tt> is the RPM
+ release number as determined above. Go to the displayed URL and
+ release the file publicly on Sourceforge. Use the release notes and
+ change log from the source tarball package.</p>
+ </div>
+
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="NEWRELEASE-OS2" id="NEWRELEASE-OS2">6.3.4.
+ OS/2</a></h3>
+
+ <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
+ freshly exported the right version into an empty directory</span>.
+ (See "Building and releasing packages" above). Then get the OS/2
+ Setup module:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co os2setup
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- You will need a mix of development tools. The main compilation
- takes place with IBM Visual Age C++. Some ancillary work takes
- place with GNU tools, available from various sources like
- hobbes.nmsu.edu. Specificially, you will need <tt class=
- "FILENAME">autoheader</tt>, <tt class="FILENAME">autoconf</tt>
- and <tt class="FILENAME">sh</tt> tools. The packaging takes place
- with WarpIN, available from various sources, including its home
- page: <a href="http://www.xworkplace.org/" target=
- "_top">xworkplace</a>.
- </p>
- <p>
- Change directory to the <tt class="FILENAME">os2setup</tt>
- directory. Edit the os2build.cmd file to set the final executable
- filename. For example,
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>You will need a mix of development tools. The main compilation
+ takes place with IBM Visual Age C++. Some ancillary work takes place
+ with GNU tools, available from various sources like hobbes.nmsu.edu.
+ Specificially, you will need <tt class="FILENAME">autoheader</tt>,
+ <tt class="FILENAME">autoconf</tt> and <tt class="FILENAME">sh</tt>
+ tools. The packaging takes place with WarpIN, available from various
+ sources, including its home page: <a href=
+ "http://www.xworkplace.org/" target="_top">xworkplace</a>.</p>
+
+ <p>Change directory to the <tt class="FILENAME">os2setup</tt>
+ directory. Edit the os2build.cmd file to set the final executable
+ filename. For example,</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
installExeName='privoxyos2_setup_X.Y.Z.exe'
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- Next, edit the <tt class="FILENAME">IJB.wis</tt> file so the
- release number matches in the <tt class="FILENAME">PACKAGEID</tt>
- section:
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>Next, edit the <tt class="FILENAME">IJB.wis</tt> file so the
+ release number matches in the <tt class="FILENAME">PACKAGEID</tt>
+ section:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
PACKAGEID="Privoxy Team\Privoxy\Privoxy Package\X\Y\Z"
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- You're now ready to build. Run:
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>You're now ready to build. Run:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
os2build
</pre>
- </td>
- </tr>
- </table>
+ </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>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>You will find the WarpIN-installable executable in the <tt class=
+ "FILENAME">./files</tt> directory. Upload this anonymously to
+ <tt class="FILENAME">uploads.sourceforge.net/incoming</tt>, create a
+ release for it, and you're done. Use the release notes and Change Log
+ from the source tarball package.</p>
+ </div>
+
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="NEWRELEASE-SOLARIS" id=
+ "NEWRELEASE-SOLARIS">6.3.5. Solaris</a></h3>
+
+ <p>Login to Sourceforge's compilefarm via ssh:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
ssh cf.sourceforge.net
</pre>
- </td>
- </tr>
- </table>
+ </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>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>Choose the right operating system (not the Debian one). When
+ logged in, <span class="emphasis EMPHASIS c2">make sure that you have
+ freshly exported the right version into an empty directory</span>.
+ (See "Building and releasing packages" above). Then run:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
cd current
autoheader && autoconf && ./configure
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- Then run
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>Then run</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
gmake solaris-dist
</pre>
- </td>
- </tr>
- </table>
+ </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>
- You should ensure you have the latest version of Cygwin (from <a
- href="http://www.cygwin.com/" target=
- "_top">http://www.cygwin.com/</a>). Run the following commands
- from within a Cygwin bash shell.
- </p>
- <p>
- First, <span class="emphasis"><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>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>which creates a gzip'ed tar archive. Sadly, you cannot use
+ <b class="COMMAND">make solaris-upload</b> on the Sourceforge machine
+ (no ncftpput). You now have to manually upload the archive to
+ Sourceforge's ftp server and release the file publicly. Use the
+ release notes and Change Log from the source tarball package.</p>
+ </div>
+
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="NEWRELEASE-WINDOWS" id=
+ "NEWRELEASE-WINDOWS">6.3.6. Windows</a></h3>
+
+ <p>You should ensure you have the latest version of Cygwin (from
+ <a href="http://www.cygwin.com/" target=
+ "_top">http://www.cygwin.com/</a>). Run the following commands from
+ within a Cygwin bash shell.</p>
+
+ <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
+ freshly exported the right version into an empty directory</span>.
+ (See "Building and releasing packages" above). Then get the Windows
+ setup module:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co winsetup
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- Then you can build the package. This is fully automated, and is
- controlled by <tt class="FILENAME">winsetup/GNUmakefile</tt>. All
- you need to do is:
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>Then you can build the package. This is fully automated, and is
+ controlled by <tt class="FILENAME">winsetup/GNUmakefile</tt>. All you
+ need to do is:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
cd winsetup
make
</pre>
- </td>
- </tr>
- </table>
+ </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>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
- debchange -v 3.0.18-UNRELEASED-1 "New upstream version"
+ <p>Now you can manually rename <tt class=
+ "FILENAME">privoxy_setup.exe</tt> to <tt class=
+ "FILENAME">privoxy_setup_X_Y_Z.exe</tt>, and upload it to
+ SourceForge. When releasing the package on SourceForge, use the
+ release notes and Change Log from the source tarball package.</p>
+ </div>
+
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="NEWRELEASE-DEBIAN" id=
+ "NEWRELEASE-DEBIAN">6.3.7. Debian</a></h3>
+
+ <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
+ freshly exported the right version into an empty directory</span>.
+ (See "Building and releasing packages" above). Then add a log entry
+ to <tt class="FILENAME">debian/changelog</tt>, if it is not already
+ there, for example by running:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
+ debchange -v 3.0.18-stable-1 "New upstream version"
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- Then, run:
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>Then, run:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
dpkg-buildpackage -rfakeroot -us -uc -b
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- This will create <tt class=
- "FILENAME">../privoxy_3.0.18-UNRELEASED-1_i386.deb</tt> which can
- be uploaded. To upload the package to Sourceforge, simply issue
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>This will create <tt class=
+ "FILENAME">../privoxy_3.0.18-stable-1_i386.deb</tt> which can be
+ uploaded. To upload the package to Sourceforge, simply issue</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
make debian-upload
</pre>
- </td>
- </tr>
- </table>
- </div>
- <div class="SECT3">
- <h3 class="SECT3">
- <a name="NEWRELEASE-MACOSX">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). Then get the Mac OS X setup module:
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ </td>
+ </tr>
+ </table>
+ </div>
+
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="NEWRELEASE-MACOSX" id=
+ "NEWRELEASE-MACOSX">6.3.8. Mac OS X</a></h3>
+
+ <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
+ freshly exported the right version into an empty directory</span>.
+ (See "Building and releasing packages" above). Then get the Mac OS X
+ setup module:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co osxsetup
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- Then run:
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>Then run:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
cd osxsetup
build
</pre>
- </td>
- </tr>
- </table>
+ </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>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>This will run <tt class="FILENAME">autoheader</tt>, <tt class=
+ "FILENAME">autoconf</tt> and <tt class="FILENAME">configure</tt> as
+ well as <tt class="FILENAME">make</tt>. Finally, it will copy over
+ the necessary files to the ./osxsetup/files directory for further
+ processing by <tt class="FILENAME">PackageMaker</tt>.</p>
+
+ <p>Bring up PackageMaker with the PrivoxyPackage.pmsp definition
+ file, modify the package name to match the release, and hit the
+ "Create package" button. If you specify ./Privoxy.pkg as the output
+ package name, you can then create the distributable zip file with the
+ command:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- You can then upload <tt class=
- "FILENAME">privoxyosx_setup_x.y.z.zip</tt> anonymously to <tt
- class="FILENAME">uploads.sourceforge.net/incoming</tt>, create a
- release for it, and you're done. Use the release notes and Change
- Log from the source tarball package.
- </p>
- </div>
- <div class="SECT3">
- <h3 class="SECT3">
- <a name="NEWRELEASE-FREEBSD">6.3.9. FreeBSD</a>
- </h3>
- <p>
- Login to Sourceforge's compile-farm via ssh:
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>You can then upload <tt class=
+ "FILENAME">privoxyosx_setup_x.y.z.zip</tt> anonymously to <tt class=
+ "FILENAME">uploads.sourceforge.net/incoming</tt>, create a release
+ for it, and you're done. Use the release notes and Change Log from
+ the source tarball package.</p>
+ </div>
+
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="NEWRELEASE-FREEBSD" id=
+ "NEWRELEASE-FREEBSD">6.3.9. FreeBSD</a></h3>
+
+ <p>Login to Sourceforge's compile-farm via ssh:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
ssh cf.sourceforge.net
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- Choose the right operating system. 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>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>Choose the right operating system. When logged in, <span class=
+ "emphasis EMPHASIS c2">make sure that you have freshly exported the
+ right version into an empty directory</span>. (See "Building and
+ releasing packages" above). Then run:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
cd current
autoheader && autoconf && ./configure
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- Then run:
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>Then run:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
gmake freebsd-dist
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- which creates a gzip'ed tar archive. Sadly, you cannot use <b
- class="COMMAND">make freebsd-upload</b> on the Sourceforge
- machine (no ncftpput). You now have to manually upload the
- archive to Sourceforge's ftp server and release the file
- publicly. Use the release notes and Change Log from the source
- tarball package.
- </p>
- </div>
- <div class="SECT3">
- <h3 class="SECT3">
- <a name="NEWRELEASE-HPUX">6.3.10. HP-UX 11</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>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>which creates a gzip'ed tar archive. Sadly, you cannot use
+ <b class="COMMAND">make freebsd-upload</b> on the Sourceforge machine
+ (no ncftpput). You now have to manually upload the archive to
+ Sourceforge's ftp server and release the file publicly. Use the
+ release notes and Change Log from the source tarball package.</p>
+ </div>
+
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="NEWRELEASE-HPUX" id=
+ "NEWRELEASE-HPUX">6.3.10. HP-UX 11</a></h3>
+
+ <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
+ freshly exported the right version into an empty directory</span>.
+ (See "Building and releasing packages" above). Then run:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
cd current
autoheader && autoconf && ./configure
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- Then do FIXME.
- </p>
- </div>
- <div class="SECT3">
- <h3 class="SECT3">
- <a name="NEWRELEASE-AMIGA">6.3.11. Amiga OS</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>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>Then do FIXME.</p>
+ </div>
+
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="NEWRELEASE-AMIGA" id=
+ "NEWRELEASE-AMIGA">6.3.11. Amiga OS</a></h3>
+
+ <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
+ freshly exported the right version into an empty directory</span>.
+ (See "Building and releasing packages" above). Then run:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
cd current
autoheader && autoconf && ./configure
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- Then do FIXME.
- </p>
- </div>
- <div class="SECT3">
- <h3 class="SECT3">
- <a name="NEWRELEASE-AIX">6.3.12. AIX</a>
- </h3>
- <p>
- Login to Sourceforge's compilefarm via ssh:
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>Then do FIXME.</p>
+ </div>
+
+ <div class="SECT3">
+ <h3 class="SECT3"><a name="NEWRELEASE-AIX" id=
+ "NEWRELEASE-AIX">6.3.12. AIX</a></h3>
+
+ <p>Login to Sourceforge's compilefarm via ssh:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
ssh cf.sourceforge.net
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- Choose the right operating system. 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>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>Choose the right operating system. When logged in, <span class=
+ "emphasis EMPHASIS c2">make sure that you have freshly exported the
+ right version into an empty directory</span>. (See "Building and
+ releasing packages" above). Then run:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
cd current
autoheader && autoconf && ./configure
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- Then run:
- </p>
- <p>
- </p>
- <table border="0" bgcolor="#E0E0E0" width="100%">
- <tr>
- <td>
-<pre class="PROGRAMLISTING">
+ <p>Then run:</p>
+
+ <table class="c3" border="0" width="100%">
+ <tr>
+ <td>
+ <pre class="PROGRAMLISTING">
make aix-dist
</pre>
- </td>
- </tr>
- </table>
+ </td>
+ </tr>
+ </table>
- <p>
- which creates a gzip'ed tar archive. Sadly, you cannot use <b
- class="COMMAND">make aix-upload</b> on the Sourceforge machine
- (no ncftpput). You now have to manually upload the archive to
- Sourceforge's ftp server and release the file publicly. Use the
- release notes and Change Log from the source tarball package.
- </p>
- </div>
+ <p>which creates a gzip'ed tar archive. Sadly, you cannot use
+ <b class="COMMAND">make aix-upload</b> on the Sourceforge machine (no
+ ncftpput). You now have to manually upload the archive to
+ Sourceforge's ftp server and release the file publicly. Use the
+ release notes and Change Log from the source tarball package.</p>
</div>
- <div 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>
+ </div>
- <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.18
- (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:ijbswa-announce@lists.sourceforge.net" target=
- "_top">announce mailing list</a>, Subject: "Version X.Y.Z available
- for download". Be sure to include the <a href=
- "http://sourceforge.net/project/showfiles.php?group_id=11118"
- target="_top">download location</a>, the release notes and the
- Changelog. Also, post an updated News item on the project page
- Sourceforge, and update the Home page and docs linked from the Home
- page (see below). Other news sites and release oriented sites, such
- as Freshmeat, should also be notified.
- </p>
- </div>
+ <div class="SECT2">
+ <h2 class="SECT2"><a name="RELEASING" id="RELEASING">6.4. Uploading and
+ Releasing Your Package</a></h2>
+
+ <p>After the package is ready, it is time to upload it to SourceForge,
+ and go through the release steps. The upload is done via FTP:</p>
+
+ <ul>
+ <li>
+ <p>Upload to: <a href="ftp://upload.sourceforge.net/incoming"
+ target="_top">ftp://upload.sourceforge.net/incoming</a></p>
+ </li>
+
+ <li>
+ <p>user: <tt class="LITERAL">anonymous</tt></p>
+ </li>
+
+ <li>
+ <p>password: <tt class=
+ "LITERAL">ijbswa-developers@lists.sourceforge.net</tt></p>
+ </li>
+ </ul>
+
+ <p>Or use the <b class="COMMAND">make</b> targets as described
+ above.</p>
+
+ <p>Once this done go to <a href=
+ "https://sourceforge.net/project/admin/editpackages.php?group_id=11118"
+ target=
+ "_top">https://sourceforge.net/project/admin/editpackages.php?group_id=11118</a>,
+ making sure you are logged in. Find your target platform in the second
+ column, and click <tt class="LITERAL">Add Release</tt>. You will then
+ need to create a new release for your package, using the format of
+ <tt class="LITERAL">$VERSION ($CODE_STATUS)</tt>, e.g. <span class=
+ "emphasis EMPHASIS c2">3.0.18 (beta)</span>.</p>
+
+ <p>Now just follow the prompts. Be sure to add any appropriate Release
+ notes. You should see your freshly uploaded packages in <span class=
+ "QUOTE">"Step 2. Add Files To This Release"</span>. Check the
+ appropriate box(es). Remember at each step to hit the <span class=
+ "QUOTE">"Refresh/Submit"</span> buttons! You should now see your
+ file(s) listed in Step 3. Fill out the forms with the appropriate
+ information for your platform, being sure to hit <span class=
+ "QUOTE">"Update"</span> for each file. If anyone is monitoring your
+ platform, check the <span class="QUOTE">"email"</span> box at the very
+ bottom to notify them of the new package. This should do it!</p>
+
+ <p>If you have made errors, or need to make changes, you can go through
+ essentially the same steps, but select <tt class="LITERAL">Edit
+ Release</tt>, instead of <tt class="LITERAL">Add Release</tt>.</p>
</div>
- <div class="NAVFOOTER">
- <hr width="100%" class="c1">
- <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 class="SECT2">
+ <h2 class="SECT2"><a name="AFTERRELEASE" id="AFTERRELEASE">6.5. After
+ the Release</a></h2>
+
+ <p>When all (or: most of the) packages have been uploaded and made
+ available, send an email to the <a href=
+ "mailto:ijbswa-announce@lists.sourceforge.net" target="_top">announce
+ mailing list</a>, Subject: "Version X.Y.Z available for download". Be
+ sure to include the <a href=
+ "http://sourceforge.net/project/showfiles.php?group_id=11118" target=
+ "_top">download location</a>, the release notes and the Changelog.
+ Also, post an updated News item on the project page Sourceforge, and
+ update the Home page and docs linked from the Home page (see below).
+ Other news sites and release oriented sites, such as Freshmeat, should
+ also be notified.</p>
</div>
- </body>
-</html>
+ </div>
+ <div class="NAVFOOTER">
+ <hr class="c1" width="100%">
+
+ <table summary="Footer navigation table" width="100%" border="0"
+ cellpadding="0" cellspacing="0">
+ <tr>
+ <td width="33%" align="left" valign="top"><a href="testing.html"
+ accesskey="P">Prev</a></td>
+
+ <td width="34%" align="center" valign="top"><a href="index.html"
+ accesskey="H">Home</a></td>
+
+ <td width="33%" align="right" valign="top"><a href=
+ "webserver-update.html" accesskey="N">Next</a></td>
+ </tr>
+
+ <tr>
+ <td width="33%" align="left" valign="top">Testing Guidelines</td>
+
+ <td width="34%" align="center" valign="top"> </td>
+
+ <td width="33%" align="right" valign="top">Update the Webserver</td>
+ </tr>
+ </table>
+ </div>
+</body>
+</html>
projects / privoxy.git / blobdiff