1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
2 "http://www.w3.org/TR/html4/loose.dtd">
6 <title>Releasing a New Version</title>
7 <meta name="GENERATOR" content=
8 "Modular DocBook HTML Stylesheet Version 1.79">
9 <link rel="HOME" title="Privoxy Developer Manual" href="index.html">
10 <link rel="PREVIOUS" title="Testing Guidelines" href="testing.html">
11 <link rel="NEXT" title="Update the Webserver" href="webserver-update.html">
12 <link rel="STYLESHEET" type="text/css" href="../p_doc.css">
13 <meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
14 <style type="text/css">
16 background-color: #EEEEEE;
19 :link { color: #0000FF }
20 :visited { color: #840084 }
21 :active { color: #0000FF }
22 tt.c5 {font-style: italic}
23 td.c4 {font-weight: bold}
24 table.c3 {background-color: #E0E0E0}
25 span.c2 {font-style: italic}
26 hr.c1 {text-align: left}
31 <div class="NAVHEADER">
32 <table summary="Header navigation table" width="100%" border="0"
33 cellpadding="0" cellspacing="0">
35 <th colspan="3" align="center">Privoxy Developer Manual</th>
39 <td width="10%" align="left" valign="bottom"><a href="testing.html"
40 accesskey="P">Prev</a></td>
42 <td width="80%" align="center" valign="bottom"></td>
44 <td width="10%" align="right" valign="bottom"><a href=
45 "webserver-update.html" accesskey="N">Next</a></td>
48 <hr class="c1" width="100%">
52 <h1 class="SECT1"><a name="NEWRELEASE" id="NEWRELEASE">6. Releasing a New
55 <p>When we release versions of <span class="APPLICATION">Privoxy</span>,
56 our work leaves our cozy secret lab and has to work in the cold
57 RealWorld[tm]. Once it is released, there is no way to call it back, so
58 it is very important that great care is taken to ensure that everything
59 runs fine, and not to introduce problems in the very last minute.</p>
61 <p>So when releasing a new version, please adhere exactly to the
62 procedure outlined in this chapter.</p>
64 <p>The following programs are required to follow this process: <tt class=
65 "FILENAME">ncftpput</tt> (ncftp), <tt class="FILENAME">scp, ssh</tt>
66 (ssh), <tt class="FILENAME">gmake</tt> (GNU's version of make), autoconf,
70 <h2 class="SECT2"><a name="VERSIONNUMBERS" id="VERSIONNUMBERS">6.1.
71 Version numbers</a></h2>
73 <p>First you need to determine which version number the release will
74 have. <span class="APPLICATION">Privoxy</span> version numbers consist
75 of three numbers, separated by dots, like in X.Y.Z (e.g. 3.0.0),
80 <p>X, the version major, is rarely ever changed. It is increased by
81 one if turning a development branch into stable substantially
82 changes the functionality, user interface or configuration syntax.
83 Majors 1 and 2 were <span class="APPLICATION">Junkbuster</span>,
84 and 3 will be the first stable <span class=
85 "APPLICATION">Privoxy</span> release.</p>
89 <p>Y, the version minor, represents the branch within the major
90 version. At any point in time, there are two branches being
91 maintained: The stable branch, with an even minor, say, 2N, in
92 which no functionality is being added and only bug-fixes are made,
93 and 2N+1, the development branch, in which the further development
94 of <span class="APPLICATION">Privoxy</span> takes place. This
95 enables us to turn the code upside down and inside out, while at
96 the same time providing and maintaining a stable version. The minor
97 is reset to zero (and one) when the major is incremented. When a
98 development branch has matured to the point where it can be turned
99 into stable, the old stable branch 2N is given up (i.e. no longer
100 maintained), the former development branch 2N+1 becomes the new
101 stable branch 2N+2, and a new development branch 2N+3 is
106 <p>Z, the point or sub version, represents a release of the
107 software within a branch. It is therefore incremented immediately
108 before each code freeze. In development branches, only the even
109 point versions correspond to actual releases, while the odd ones
110 denote the evolving state of the sources on CVS in between. It
111 follows that Z is odd on CVS in development branches most of the
112 time. There, it gets increased to an even number immediately before
113 a code freeze, and is increased to an odd number again immediately
114 thereafter. This ensures that builds from CVS snapshots are easily
115 distinguished from released versions. The point version is reset to
116 zero when the minor changes.</p>
118 <p>Stable branches work a little differently, since there should be
119 little to no development happening in such branches. Remember, only
120 bugfixes, which presumably should have had some testing before
121 being committed. Stable branches will then have their version
122 reported as <tt class="LITERAL">0.0.0</tt>, during that period
123 between releases when changes are being added. This is to denote
124 that this code is <span class="emphasis EMPHASIS c2">not for
125 release</span>. Then as the release nears, the version is bumped
126 according: e.g. <tt class="LITERAL">3.0.1 -> 0.0.0 ->
131 <p>In summary, the main CVS trunk is the development branch where new
132 features are being worked on for the next stable series. This should
133 almost always be where the most activity takes place. There is always
134 at least one stable branch from the trunk, e.g now it is <tt class=
135 "LITERAL">3.0</tt>, which is only used to release stable versions. Once
136 the initial *.0 release of the stable branch has been done, then as a
137 rule, only bugfixes that have had prior testing should be committed to
138 the stable branch. Once there are enough bugfixes to justify a new
139 release, the version of this branch is again incremented Example: 3.0.0
140 -> 3.0.1 -> 3.0.2, etc are all stable releases from within the
141 stable branch. 3.1.x is currently the main trunk, and where work on
142 3.2.x is taking place. If any questions, please post to the devel list
143 <span class="emphasis EMPHASIS c2">before</span> committing to a stable
146 <p>Developers should remember too that if they commit a bugfix to the
147 stable branch, this will more than likely require a separate submission
148 to the main trunk, since these are separate development trees within
149 CVS. If you are working on both, then this would require at least two
150 separate check outs (i.e main trunk, <span class=
151 "emphasis EMPHASIS c2">and</span> the stable release branch, which is
152 <tt class="LITERAL">v_3_0_branch</tt> at the moment).</p>
156 <h2 class="SECT2"><a name="BEFORERELEASE" id="BEFORERELEASE">6.2.
157 Before the Release: Freeze</a></h2>
159 <p>The following <span class="emphasis EMPHASIS c2">must be done by one
160 of the developers</span> prior to each new release.</p>
164 <p>Make sure that everybody who has worked on the code in the last
165 couple of days has had a chance to yell <span class=
166 "QUOTE">"no!"</span> in case they have pending changes/fixes in
167 their pipelines. Announce the freeze so that nobody will interfere
168 with last minute changes.</p>
172 <p>Increment the version number (point from odd to even in
173 development branches!) in <tt class="FILENAME">configure.in</tt>.
174 (RPM spec files will need to be incremented as well.)</p>
178 <p>If <tt class="FILENAME">default.action</tt> has changed since
179 last release (i.e. software release or standalone actions file
180 release), bump up its version info to A.B in this line:</p>
182 <table class="c3" border="0" width="90%">
185 <pre class="PROGRAMLISTING">
186 {+add-header{X-Actions-File-Version: A.B} -filter -no-popups}
192 <p>Then change the version info in doc/webserver/actions/index.php,
193 line: '$required_actions_file_version = "A.B";'</p>
197 <p>All documentation should be rebuild after the version bump.
198 Finished docs should be then be committed to CVS (for those without
199 the ability to build these). Some docs may require rather obscure
200 processing tools. <tt class="FILENAME">config</tt>, the man page
201 (and the html version of the man page), and the PDF docs fall in
202 this category. REAMDE, the man page, AUTHORS, and config should all
203 also be committed to CVS for other packagers. The formal docs
204 should be uploaded to the webserver. See the Section "Updating the
205 webserver" in this manual for details.</p>
209 <p>The <i class="CITETITLE">User Manual</i> is also used for
210 context sensitive help for the CGI editor. This is version
211 sensitive, so that the user will get appropriate help for his/her
212 release. So with each release a fresh version should be uploaded to
213 the webserver (this is in addition to the main <i class=
214 "CITETITLE">User Manual</i> link from the main page since we need
215 to keep manuals for various versions available). The CGI pages will
216 link to something like <tt class=
217 "LITERAL">http://privoxy.org/$(VERSION)/user-manual/</tt>. This
218 will need to be updated for each new release. There is no Makefile
219 target for this at this time!!! It needs to be done manually.</p>
223 <p>All developers should look at the <tt class=
224 "FILENAME">ChangeLog</tt> and make sure noteworthy changes are
229 <p><span class="emphasis EMPHASIS c2">Commit all files that were
230 changed in the above steps!</span></p>
234 <p>Tag all files in CVS with the version number with <span class=
235 "QUOTE">"<b class="COMMAND">cvs tag v_X_Y_Z</b>"</span>. Don't use
236 vX_Y_Z, ver_X_Y_Z, v_X.Y.Z (won't work) etc.</p>
240 <p>If the release was in a development branch, increase the point
241 version from even to odd (X.Y.(Z+1)) again in <tt class=
242 "FILENAME">configure.in</tt> and commit your change.</p>
246 <p>On the webserver, copy the user manual to a new top-level
247 directory called <tt class="FILENAME">X.Y.Z</tt>. This ensures that
248 help links from the CGI pages, which have the version as a prefix,
249 will go into the right version of the manual. If this is a
250 development branch release, also symlink <tt class=
251 "FILENAME">X.Y.(Z-1)</tt> to <tt class="FILENAME">X.Y.Z</tt> and
252 <tt class="FILENAME">X.Y.(Z+1)</tt> to <tt class="FILENAME">.</tt>
259 <h2 class="SECT2"><a name="THERELEASE" id="THERELEASE">6.3. Building
260 and Releasing the Packages</a></h2>
262 <p>Now the individual packages can be built and released. Note that for
263 GPL reasons the first package to be released is always the source
266 <p>For <span class="emphasis EMPHASIS c2">all</span> types of packages,
267 including the source tarball, <span class="emphasis EMPHASIS c2">you
268 must make sure that you build from clean sources by exporting the right
269 version from CVS into an empty directory</span> (just press return when
270 asked for a password):</p>
272 <table class="c3" border="0" width="100%">
275 <pre class="PROGRAMLISTING">
276 mkdir dist # delete or choose different name if it already exists
278 cvs -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa login
279 cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa export -r v_X_Y_Z current
285 <p><span class="emphasis EMPHASIS c2">Do NOT change</span> a single
286 bit, including, but not limited to version information after export
287 from CVS. This is to make sure that all release packages, and with
288 them, all future bug reports, are based on exactly the same code.</p>
290 <div class="WARNING">
291 <table class="WARNING" border="1" width="100%">
293 <td class="c4" align="center">Warning</td>
298 <p>Every significant release of Privoxy has included at least
299 one package that either had incorrect versions of files,
300 missing files, or incidental leftovers from a previous build
301 process that gave unknown numbers of users headaches to try to
302 figure out what was wrong. PLEASE, make sure you are using
303 pristene sources, and are following the prescribed process!</p>
309 <p>Please find additional instructions for the source tarball and the
310 individual platform dependent binary packages below. And details on the
311 Sourceforge release process below that.</p>
314 <h3 class="SECT3"><a name="PACK-GUIDELINES" id=
315 "PACK-GUIDELINES">6.3.1. Note on Privoxy Packaging</a></h3>
317 <p>Please keep these general guidelines in mind when putting together
318 your package. These apply to <span class=
319 "emphasis EMPHASIS c2">all</span> platforms!</p>
323 <p><span class="APPLICATION">Privoxy</span> <span class=
324 "emphasis EMPHASIS c2">requires</span> write access to: all
325 <tt class="FILENAME">*.action</tt> files, all logfiles, and the
326 <tt class="FILENAME">trust</tt> file. You will need to determine
327 the best way to do this for your platform.</p>
331 <p>Please include up to date documentation. At a bare
337 <td><tt class="FILENAME">LICENSE</tt> (top-level
346 <td><tt class="FILENAME">README</tt> (top-level
355 <td><tt class="FILENAME">AUTHORS</tt> (top-level
364 <td><tt class="FILENAME">man page</tt> (top-level
365 directory, Unix-like platforms only)</td>
373 <td><tt class="FILENAME">The User Manual</tt>
374 (doc/webserver/user-manual/)</td>
382 <td><tt class="FILENAME">FAQ</tt> (doc/webserver/faq/)</td>
387 <p>Also suggested: <tt class="FILENAME">Developer Manual</tt>
388 (doc/webserver/developer-manual) and <tt class=
389 "FILENAME">ChangeLog</tt> (top-level directory). <tt class=
390 "FILENAME">FAQ</tt> and the manuals are HTML docs. There are also
391 text versions in <tt class="FILENAME">doc/text/</tt> which could
392 conceivably also be included.</p>
394 <p>The documentation has been designed such that the manuals are
395 linked to each other from parallel directories, and should be
396 packaged that way. <tt class="FILENAME">privoxy-index.html</tt>
397 can also be included and can serve as a focal point for docs and
398 other links of interest (and possibly renamed to <tt class=
399 "FILENAME">index.html</tt>). This should be one level up from the
400 manuals. There is a link also on this page to an HTMLized version
401 of the man page. To avoid 404 for this, it is in CVS as
402 <tt class="FILENAME">doc/webserver/man-page/privoxy-man-page.html</tt>,
403 and should be included along with the manuals. There is also a
404 css stylesheets that can be included for better presentation:
405 <tt class="FILENAME">p_doc.css</tt>. This should be in the same
406 directory with <tt class="FILENAME">privoxy-index.html</tt>,
407 (i.e. one level up from the manual directories).</p>
411 <p><tt class="FILENAME">user.action</tt> and <tt class=
412 "FILENAME">user.filter</tt> are designed for local preferences.
413 Make sure these do not get overwritten! <tt class=
414 "FILENAME">config</tt> should not be overwritten either. This has
415 especially important configuration data in it. <tt class=
416 "FILENAME">trust</tt> should be left in tact as well.</p>
420 <p>Other configuration files (<tt class=
421 "FILENAME">default.action</tt> and <tt class=
422 "FILENAME">default.filter</tt>) should be installed as the new
423 defaults, but all previously installed configuration files should
424 be preserved as backups. This is just good manners :-) These
425 files are likely to change between releases and contain important
426 new features and bug fixes.</p>
430 <p>Please check platform specific notes in this doc, if you
431 haven't done <span class="QUOTE">"Privoxy"</span> packaging
432 before for other platform specific issues. Conversely, please add
433 any notes that you know are important for your platform (or
434 contact one of the doc maintainers to do this if you can't).</p>
438 <p>Packagers should do a <span class="QUOTE">"clean"</span>
439 install of their package after building it. So any previous
440 installs should be removed first to ensure the integrity of the
441 newly built package. Then run the package for a while to make
442 sure there are no obvious problems, before uploading.</p>
448 <h3 class="SECT3"><a name="NEWRELEASE-TARBALL" id=
449 "NEWRELEASE-TARBALL">6.3.2. Source Tarball</a></h3>
451 <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
452 freshly exported the right version into an empty directory</span>.
453 (See "Building and releasing packages" above). Then run:</p>
455 <table class="c3" border="0" width="100%">
458 <pre class="PROGRAMLISTING">
460 autoheader && autoconf && ./configure
468 <table class="c3" border="0" width="100%">
471 <pre class="PROGRAMLISTING">
478 <p>To upload the package to Sourceforge, simply issue</p>
480 <table class="c3" border="0" width="100%">
483 <pre class="PROGRAMLISTING">
490 <p>Go to the displayed URL and release the file publicly on
491 Sourceforge. For the change log field, use the relevant section of
492 the <tt class="FILENAME">ChangeLog</tt> file.</p>
496 <h3 class="SECT3"><a name="NEWRELEASE-RPM" id="NEWRELEASE-RPM">6.3.3.
497 SuSE, Conectiva or Red Hat RPM</a></h3>
499 <p>In following text, replace <tt class="REPLACEABLE c5">dist</tt>
500 with either <span class="QUOTE">"rh"</span> for Red Hat or
501 <span class="QUOTE">"suse"</span> for SuSE.</p>
503 <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
504 freshly exported the right version into an empty directory</span>.
505 (See "Building and releasing packages" above).</p>
507 <p>As the only exception to not changing anything after export from
508 CVS, now examine the file <tt class=
509 "FILENAME">privoxy-</tt><tt class="REPLACEABLE c5">dist</tt><tt class="FILENAME">.spec</tt>
510 and make sure that the version information and the RPM release number
511 are correct. The RPM release numbers for each version start at one.
512 Hence it must be reset to one if this is the first RPM for <tt class=
513 "REPLACEABLE c5">dist</tt> which is built from version X.Y.Z. Check
515 "http://sourceforge.net/project/showfiles.php?group_id=11118" target=
516 "_top">file list</a> if unsure. Else, it must be set to the highest
517 already available RPM release number for that version plus one.</p>
521 <table class="c3" border="0" width="100%">
524 <pre class="PROGRAMLISTING">
526 autoheader && autoconf && ./configure
534 <table class="c3" border="0" width="100%">
537 <pre class="PROGRAMLISTING">
538 make <tt class="REPLACEABLE c5">dist</tt>-dist
544 <p>To upload the package to Sourceforge, simply issue</p>
546 <table class="c3" border="0" width="100%">
549 <pre class="PROGRAMLISTING">
550 make <tt class="REPLACEABLE c5">dist</tt>-upload <tt class=
551 "REPLACEABLE c5">rpm_packagerev</tt>
557 <p>where <tt class="REPLACEABLE c5">rpm_packagerev</tt> is the RPM
558 release number as determined above. Go to the displayed URL and
559 release the file publicly on Sourceforge. Use the release notes and
560 change log from the source tarball package.</p>
564 <h3 class="SECT3"><a name="NEWRELEASE-OS2" id="NEWRELEASE-OS2">6.3.4.
567 <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
568 freshly exported the right version into an empty directory</span>.
569 (See "Building and releasing packages" above). Then get the OS/2
572 <table class="c3" border="0" width="100%">
575 <pre class="PROGRAMLISTING">
576 cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co os2setup
582 <p>You will need a mix of development tools. The main compilation
583 takes place with IBM Visual Age C++. Some ancillary work takes place
584 with GNU tools, available from various sources like hobbes.nmsu.edu.
585 Specificially, you will need <tt class="FILENAME">autoheader</tt>,
586 <tt class="FILENAME">autoconf</tt> and <tt class="FILENAME">sh</tt>
587 tools. The packaging takes place with WarpIN, available from various
588 sources, including its home page: <a href=
589 "http://www.xworkplace.org/" target="_top">xworkplace</a>.</p>
591 <p>Change directory to the <tt class="FILENAME">os2setup</tt>
592 directory. Edit the os2build.cmd file to set the final executable
593 filename. For example,</p>
595 <table class="c3" border="0" width="100%">
598 <pre class="PROGRAMLISTING">
599 installExeName='privoxyos2_setup_X.Y.Z.exe'
605 <p>Next, edit the <tt class="FILENAME">IJB.wis</tt> file so the
606 release number matches in the <tt class="FILENAME">PACKAGEID</tt>
609 <table class="c3" border="0" width="100%">
612 <pre class="PROGRAMLISTING">
613 PACKAGEID="Privoxy Team\Privoxy\Privoxy Package\X\Y\Z"
619 <p>You're now ready to build. Run:</p>
621 <table class="c3" border="0" width="100%">
624 <pre class="PROGRAMLISTING">
631 <p>You will find the WarpIN-installable executable in the <tt class=
632 "FILENAME">./files</tt> directory. Upload this anonymously to
633 <tt class="FILENAME">uploads.sourceforge.net/incoming</tt>, create a
634 release for it, and you're done. Use the release notes and Change Log
635 from the source tarball package.</p>
639 <h3 class="SECT3"><a name="NEWRELEASE-SOLARIS" id=
640 "NEWRELEASE-SOLARIS">6.3.5. Solaris</a></h3>
642 <p>Login to Sourceforge's compilefarm via ssh:</p>
644 <table class="c3" border="0" width="100%">
647 <pre class="PROGRAMLISTING">
648 ssh cf.sourceforge.net
654 <p>Choose the right operating system (not the Debian one). When
655 logged in, <span class="emphasis EMPHASIS c2">make sure that you have
656 freshly exported the right version into an empty directory</span>.
657 (See "Building and releasing packages" above). Then run:</p>
659 <table class="c3" border="0" width="100%">
662 <pre class="PROGRAMLISTING">
664 autoheader && autoconf && ./configure
672 <table class="c3" border="0" width="100%">
675 <pre class="PROGRAMLISTING">
682 <p>which creates a gzip'ed tar archive. Sadly, you cannot use
683 <b class="COMMAND">make solaris-upload</b> on the Sourceforge machine
684 (no ncftpput). You now have to manually upload the archive to
685 Sourceforge's ftp server and release the file publicly. Use the
686 release notes and Change Log from the source tarball package.</p>
690 <h3 class="SECT3"><a name="NEWRELEASE-WINDOWS" id=
691 "NEWRELEASE-WINDOWS">6.3.6. Windows</a></h3>
693 <p>You should ensure you have the latest version of Cygwin (from
694 <a href="http://www.cygwin.com/" target=
695 "_top">http://www.cygwin.com/</a>). Run the following commands from
696 within a Cygwin bash shell.</p>
698 <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
699 freshly exported the right version into an empty directory</span>.
700 (See "Building and releasing packages" above). Then get the Windows
703 <table class="c3" border="0" width="100%">
706 <pre class="PROGRAMLISTING">
707 cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co winsetup
713 <p>Then you can build the package. This is fully automated, and is
714 controlled by <tt class="FILENAME">winsetup/GNUmakefile</tt>. All you
717 <table class="c3" border="0" width="100%">
720 <pre class="PROGRAMLISTING">
728 <p>Now you can manually rename <tt class=
729 "FILENAME">privoxy_setup.exe</tt> to <tt class=
730 "FILENAME">privoxy_setup_X_Y_Z.exe</tt>, and upload it to
731 SourceForge. When releasing the package on SourceForge, use the
732 release notes and Change Log from the source tarball package.</p>
736 <h3 class="SECT3"><a name="NEWRELEASE-DEBIAN" id=
737 "NEWRELEASE-DEBIAN">6.3.7. Debian</a></h3>
739 <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
740 freshly exported the right version into an empty directory</span>.
741 (See "Building and releasing packages" above). Then add a log entry
742 to <tt class="FILENAME">debian/changelog</tt>, if it is not already
743 there, for example by running:</p>
745 <table class="c3" border="0" width="100%">
748 <pre class="PROGRAMLISTING">
749 debchange -v 3.0.20-UNRELEASED-1 "New upstream version"
757 <table class="c3" border="0" width="100%">
760 <pre class="PROGRAMLISTING">
761 dpkg-buildpackage -rfakeroot -us -uc -b
767 <p>This will create <tt class=
768 "FILENAME">../privoxy_3.0.20-UNRELEASED-1_i386.deb</tt> which can be
769 uploaded. To upload the package to Sourceforge, simply issue</p>
771 <table class="c3" border="0" width="100%">
774 <pre class="PROGRAMLISTING">
783 <h3 class="SECT3"><a name="NEWRELEASE-MACOSX" id=
784 "NEWRELEASE-MACOSX">6.3.8. Mac OS X</a></h3>
786 <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
787 freshly exported the right version into an empty directory</span>.
788 (See "Building and releasing packages" above).</p>
790 <p>There are three modules available in the CVS repository for use on
791 Mac OS X, though technically only two of them generate a release (the
792 other can be used to install from source).</p>
795 <h4 class="SECT4"><a name="OS-X-OSXPACKAGEBUILDER-MODULE" id=
796 "OS-X-OSXPACKAGEBUILDER-MODULE">6.3.8.1. OSXPackageBuilder
799 <p>The OSXPackageBuilder module generates OS X installer packages
800 supporting all Macs running OS X 10.4 and above. Obtain it from CVS
801 as follows into a folder parallel to the exported privoxy
804 <table class="c3" border="0" width="100%">
807 <pre class="PROGRAMLISTING">
808 cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co OSXPackageBuilder
814 <p>The module contains complete instructions on its usage in the
815 file <tt class="FILENAME">OS X Package Builder HOWTO.txt</tt>.</p>
817 <p>Once the package(s) have been generated, you can then upload
818 them directly to the Files section of the Sourceforge project in
819 the Macintosh (OS X) folder. Each new version release of Privoxy
820 should have a new subfolder created in which to store its files.
821 Please ensure that the folder contains a readme file that makes it
822 clear which package is for whichversion of OS X.</p>
826 <h4 class="SECT4"><a name="OS-X-OSXSETUP-MODULE" id=
827 "OS-X-OSXSETUP-MODULE">6.3.8.2. osxsetup module
828 (DEPRECATED)</a></h4>
830 <p><span class="emphasis EMPHASIS c2">This module is deprecated
831 since the installer it generates places all Privoxy files in one
832 folder in a non-standard location, and supports only Intel Macs
833 running OS X 10.6 or higher.</span></p>
835 <p>Check out the module from CVS as follows into a folder parallel
836 to the exported privoxy source:</p>
838 <table class="c3" border="0" width="100%">
841 <pre class="PROGRAMLISTING">
842 cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co osxsetup
850 <table class="c3" border="0" width="100%">
853 <pre class="PROGRAMLISTING">
861 <p>This will run <tt class="FILENAME">autoheader</tt>, <tt class=
862 "FILENAME">autoconf</tt> and <tt class="FILENAME">configure</tt> as
863 well as <tt class="FILENAME">make</tt>. Finally, it will copy over
864 the necessary files to the ./osxsetup/files directory for further
865 processing by <tt class="FILENAME">PackageMaker</tt>.</p>
867 <p>Bring up PackageMaker with the PrivoxyPackage.pmsp definition
868 file, modify the package name to match the release, and hit the
869 "Create package" button. If you specify ./Privoxy.pkg as the output
870 package name, you can then create the distributable zip file with
873 <table class="c3" border="0" width="100%">
876 <pre class="PROGRAMLISTING">
877 zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg
883 <p>You can then upload this file directly to the Files section of
884 the Sourceforge project in the Macintosh (OS X) folder. Each new
885 version release of Privoxy should have a new subfolder created in
886 which to store its files. Please ensure that the folder contains a
887 readme file that makes it clear which version(s) of OS X the
888 package supports.</p>
892 <h4 class="SECT4"><a name="OS-X-MACSETUP-MODULE" id=
893 "OS-X-MACSETUP-MODULE">6.3.8.3. macsetup module</a></h4>
895 <p>The macsetup module is ideal if you wish to build and install
896 Privoxy from source on a single machine.</p>
898 <p>Check out the module from CVS as follows into a folder parallel
899 to the exported privoxy source:</p>
901 <table class="c3" border="0" width="100%">
904 <pre class="PROGRAMLISTING">
905 cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co macsetup
911 <p>The module contains complete instructions on its usage in its
912 <tt class="FILENAME">README</tt> file. The end result will be the
913 the exported version of Privoxy installed on the build machine.</p>
918 <h3 class="SECT3"><a name="NEWRELEASE-FREEBSD" id=
919 "NEWRELEASE-FREEBSD">6.3.9. FreeBSD</a></h3>
921 <p>Login to Sourceforge's compile-farm via ssh:</p>
923 <table class="c3" border="0" width="100%">
926 <pre class="PROGRAMLISTING">
927 ssh cf.sourceforge.net
933 <p>Choose the right operating system. When logged in, <span class=
934 "emphasis EMPHASIS c2">make sure that you have freshly exported the
935 right version into an empty directory</span>. (See "Building and
936 releasing packages" above). Then run:</p>
938 <table class="c3" border="0" width="100%">
941 <pre class="PROGRAMLISTING">
943 autoheader && autoconf && ./configure
951 <table class="c3" border="0" width="100%">
954 <pre class="PROGRAMLISTING">
961 <p>which creates a gzip'ed tar archive. Sadly, you cannot use
962 <b class="COMMAND">make freebsd-upload</b> on the Sourceforge machine
963 (no ncftpput). You now have to manually upload the archive to
964 Sourceforge's ftp server and release the file publicly. Use the
965 release notes and Change Log from the source tarball package.</p>
969 <h3 class="SECT3"><a name="NEWRELEASE-HPUX" id=
970 "NEWRELEASE-HPUX">6.3.10. HP-UX 11</a></h3>
972 <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
973 freshly exported the right version into an empty directory</span>.
974 (See "Building and releasing packages" above). Then run:</p>
976 <table class="c3" border="0" width="100%">
979 <pre class="PROGRAMLISTING">
981 autoheader && autoconf && ./configure
987 <p>Then do FIXME.</p>
991 <h3 class="SECT3"><a name="NEWRELEASE-AMIGA" id=
992 "NEWRELEASE-AMIGA">6.3.11. Amiga OS</a></h3>
994 <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
995 freshly exported the right version into an empty directory</span>.
996 (See "Building and releasing packages" above). Then run:</p>
998 <table class="c3" border="0" width="100%">
1001 <pre class="PROGRAMLISTING">
1003 autoheader && autoconf && ./configure
1009 <p>Then do FIXME.</p>
1013 <h3 class="SECT3"><a name="NEWRELEASE-AIX" id=
1014 "NEWRELEASE-AIX">6.3.12. AIX</a></h3>
1016 <p>Login to Sourceforge's compilefarm via ssh:</p>
1018 <table class="c3" border="0" width="100%">
1021 <pre class="PROGRAMLISTING">
1022 ssh cf.sourceforge.net
1028 <p>Choose the right operating system. When logged in, <span class=
1029 "emphasis EMPHASIS c2">make sure that you have freshly exported the
1030 right version into an empty directory</span>. (See "Building and
1031 releasing packages" above). Then run:</p>
1033 <table class="c3" border="0" width="100%">
1036 <pre class="PROGRAMLISTING">
1038 autoheader && autoconf && ./configure
1046 <table class="c3" border="0" width="100%">
1049 <pre class="PROGRAMLISTING">
1056 <p>which creates a gzip'ed tar archive. Sadly, you cannot use
1057 <b class="COMMAND">make aix-upload</b> on the Sourceforge machine (no
1058 ncftpput). You now have to manually upload the archive to
1059 Sourceforge's ftp server and release the file publicly. Use the
1060 release notes and Change Log from the source tarball package.</p>
1065 <h2 class="SECT2"><a name="RELEASING" id="RELEASING">6.4. Uploading and
1066 Releasing Your Package</a></h2>
1068 <p>After the package is ready, it is time to upload it to SourceForge,
1069 and go through the release steps. The upload is done via FTP:</p>
1073 <p>Upload to: <a href="ftp://upload.sourceforge.net/incoming"
1074 target="_top">ftp://upload.sourceforge.net/incoming</a></p>
1078 <p>user: <tt class="LITERAL">anonymous</tt></p>
1082 <p>password: <tt class=
1083 "LITERAL">ijbswa-developers@lists.sourceforge.net</tt></p>
1087 <p>Or use the <b class="COMMAND">make</b> targets as described
1090 <p>Once this done go to <a href=
1091 "https://sourceforge.net/project/admin/editpackages.php?group_id=11118"
1093 "_top">https://sourceforge.net/project/admin/editpackages.php?group_id=11118</a>,
1094 making sure you are logged in. Find your target platform in the second
1095 column, and click <tt class="LITERAL">Add Release</tt>. You will then
1096 need to create a new release for your package, using the format of
1097 <tt class="LITERAL">$VERSION ($CODE_STATUS)</tt>, e.g. <span class=
1098 "emphasis EMPHASIS c2">3.0.20 (beta)</span>.</p>
1100 <p>Now just follow the prompts. Be sure to add any appropriate Release
1101 notes. You should see your freshly uploaded packages in <span class=
1102 "QUOTE">"Step 2. Add Files To This Release"</span>. Check the
1103 appropriate box(es). Remember at each step to hit the <span class=
1104 "QUOTE">"Refresh/Submit"</span> buttons! You should now see your
1105 file(s) listed in Step 3. Fill out the forms with the appropriate
1106 information for your platform, being sure to hit <span class=
1107 "QUOTE">"Update"</span> for each file. If anyone is monitoring your
1108 platform, check the <span class="QUOTE">"email"</span> box at the very
1109 bottom to notify them of the new package. This should do it!</p>
1111 <p>If you have made errors, or need to make changes, you can go through
1112 essentially the same steps, but select <tt class="LITERAL">Edit
1113 Release</tt>, instead of <tt class="LITERAL">Add Release</tt>.</p>
1117 <h2 class="SECT2"><a name="AFTERRELEASE" id="AFTERRELEASE">6.5. After
1118 the Release</a></h2>
1120 <p>When all (or: most of the) packages have been uploaded and made
1121 available, send an email to the <a href=
1122 "mailto:ijbswa-announce@lists.sourceforge.net" target="_top">announce
1123 mailing list</a>, Subject: "Version X.Y.Z available for download". Be
1124 sure to include the <a href=
1125 "http://sourceforge.net/project/showfiles.php?group_id=11118" target=
1126 "_top">download location</a>, the release notes and the Changelog.
1127 Also, post an updated News item on the project page Sourceforge, and
1128 update the Home page and docs linked from the Home page (see below).
1129 Other news sites and release oriented sites, such as Freshmeat, should
1130 also be notified.</p>
1134 <div class="NAVFOOTER">
1135 <hr class="c1" width="100%">
1137 <table summary="Footer navigation table" width="100%" border="0"
1138 cellpadding="0" cellspacing="0">
1140 <td width="33%" align="left" valign="top"><a href="testing.html"
1141 accesskey="P">Prev</a></td>
1143 <td width="34%" align="center" valign="top"><a href="index.html"
1144 accesskey="H">Home</a></td>
1146 <td width="33%" align="right" valign="top"><a href=
1147 "webserver-update.html" accesskey="N">Next</a></td>
1151 <td width="33%" align="left" valign="top">Testing Guidelines</td>
1153 <td width="34%" align="center" valign="top"> </td>
1155 <td width="33%" align="right" valign="top">Update the Webserver</td>