1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
2 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
6 Releasing a New Version
8 <meta name="GENERATOR" content=
9 "Modular DocBook HTML Stylesheet Version 1.79">
10 <link rel="HOME" title="Privoxy Developer Manual" href="index.html">
11 <link rel="PREVIOUS" title="Testing Guidelines" href="testing.html">
12 <link rel="NEXT" title="Update the Webserver" href=
13 "webserver-update.html">
14 <link rel="STYLESHEET" type="text/css" href="../p_doc.css">
15 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
17 <body class="SECT1" bgcolor="#EEEEEE" text="#000000" link="#0000FF" vlink=
18 "#840084" alink="#0000FF">
19 <div class="NAVHEADER">
20 <table summary="Header navigation table" width="100%" border="0"
21 cellpadding="0" cellspacing="0">
23 <th colspan="3" align="center">
24 Privoxy Developer Manual
28 <td width="10%" align="left" valign="bottom">
29 <a href="testing.html" accesskey="P">Prev</a>
31 <td width="80%" align="center" valign="bottom">
33 <td width="10%" align="right" valign="bottom">
34 <a href="webserver-update.html" accesskey="N">Next</a>
38 <hr align="LEFT" width="100%">
42 <a name="NEWRELEASE">6. Releasing a New Version</a>
45 When we release versions of <span class="APPLICATION">Privoxy</span>,
46 our work leaves our cozy secret lab and has to work in the cold
47 RealWorld[tm]. Once it is released, there is no way to call it back,
48 so it is very important that great care is taken to ensure that
49 everything runs fine, and not to introduce problems in the very last
53 So when releasing a new version, please adhere exactly to the
54 procedure outlined in this chapter.
57 The following programs are required to follow this process: <tt
58 class="FILENAME">ncftpput</tt> (ncftp), <tt class="FILENAME">scp,
59 ssh</tt> (ssh), <tt class="FILENAME">gmake</tt> (GNU's version of
64 <a name="VERSIONNUMBERS">6.1. Version numbers</a>
67 First you need to determine which version number the release will
68 have. <span class="APPLICATION">Privoxy</span> version numbers
69 consist of three numbers, separated by dots, like in X.Y.Z (e.g.
75 X, the version major, is rarely ever changed. It is increased
76 by one if turning a development branch into stable
77 substantially changes the functionality, user interface or
78 configuration syntax. Majors 1 and 2 were <span class=
79 "APPLICATION">Junkbuster</span>, and 3 will be the first stable
80 <span class="APPLICATION">Privoxy</span> release.
85 Y, the version minor, represents the branch within the major
86 version. At any point in time, there are two branches being
87 maintained: The stable branch, with an even minor, say, 2N, in
88 which no functionality is being added and only bug-fixes are
89 made, and 2N+1, the development branch, in which the further
90 development of <span class="APPLICATION">Privoxy</span> takes
91 place. This enables us to turn the code upside down and inside
92 out, while at the same time providing and maintaining a stable
93 version. The minor is reset to zero (and one) when the major is
94 incremented. When a development branch has matured to the point
95 where it can be turned into stable, the old stable branch 2N is
96 given up (i.e. no longer maintained), the former development
97 branch 2N+1 becomes the new stable branch 2N+2, and a new
98 development branch 2N+3 is opened.
103 Z, the point or sub version, represents a release of the
104 software within a branch. It is therefore incremented
105 immediately before each code freeze. In development branches,
106 only the even point versions correspond to actual releases,
107 while the odd ones denote the evolving state of the sources on
108 CVS in between. It follows that Z is odd on CVS in development
109 branches most of the time. There, it gets increased to an even
110 number immediately before a code freeze, and is increased to an
111 odd number again immediately thereafter. This ensures that
112 builds from CVS snapshots are easily distinguished from
113 released versions. The point version is reset to zero when the
117 Stable branches work a little differently, since there should
118 be little to no development happening in such branches.
119 Remember, only bugfixes, which presumably should have had some
120 testing before being committed. Stable branches will then have
121 their version reported as <tt class="LITERAL">0.0.0</tt>,
122 during that period between releases when changes are being
123 added. This is to denote that this code is <span class=
124 "emphasis"><i class="EMPHASIS">not for release</i></span>. Then
125 as the release nears, the version is bumped according: e.g. <tt
126 class="LITERAL">3.0.1 -> 0.0.0 -> 3.0.2</tt>.
132 In summary, the main CVS trunk is the development branch where new
133 features are being worked on for the next stable series. This
134 should almost always be where the most activity takes place. There
135 is always at least one stable branch from the trunk, e.g now it is
136 <tt class="LITERAL">3.0</tt>, which is only used to release stable
137 versions. Once the initial *.0 release of the stable branch has
138 been done, then as a rule, only bugfixes that have had prior
139 testing should be committed to the stable branch. Once there are
140 enough bugfixes to justify a new release, the version of this
141 branch is again incremented Example: 3.0.0 -> 3.0.1 -> 3.0.2,
142 etc are all stable releases from within the stable branch. 3.1.x is
143 currently the main trunk, and where work on 3.2.x is taking place.
144 If any questions, please post to the devel list <span class=
145 "emphasis"><i class="EMPHASIS">before</i></span> committing to a
149 Developers should remember too that if they commit a bugfix to the
150 stable branch, this will more than likely require a separate
151 submission to the main trunk, since these are separate development
152 trees within CVS. If you are working on both, then this would
153 require at least two separate check outs (i.e main trunk, <span
154 class="emphasis"><i class="EMPHASIS">and</i></span> the stable
155 release branch, which is <tt class="LITERAL">v_3_0_branch</tt> at
161 <a name="BEFORERELEASE">6.2. Before the Release: Freeze</a>
164 The following <span class="emphasis"><i class="EMPHASIS">must be
165 done by one of the developers</i></span> prior to each new release.
172 Make sure that everybody who has worked on the code in the last
173 couple of days has had a chance to yell <span class=
174 "QUOTE">"no!"</span> in case they have pending changes/fixes in
175 their pipelines. Announce the freeze so that nobody will
176 interfere with last minute changes.
181 Increment the version number (point from odd to even in
182 development branches!) in <tt class=
183 "FILENAME">configure.in</tt>. (RPM spec files will need to be
184 incremented as well.)
189 If <tt class="FILENAME">default.action</tt> has changed since
190 last release (i.e. software release or standalone actions file
191 release), bump up its version info to A.B in this line:
195 <table border="0" bgcolor="#E0E0E0" width="90%">
198 <pre class="PROGRAMLISTING">
199 {+add-header{X-Actions-File-Version: A.B} -filter -no-popups}
206 Then change the version info in
207 doc/webserver/actions/index.php, line:
208 '$required_actions_file_version = "A.B";'
213 All documentation should be rebuild after the version bump.
214 Finished docs should be then be committed to CVS (for those
215 without the ability to build these). Some docs may require
216 rather obscure processing tools. <tt class=
217 "FILENAME">config</tt>, the man page (and the html version of
218 the man page) fall in this category. REAMDE, the man page,
219 AUTHORS, and config should all also be committed to CVS for
220 other packagers. The formal docs should be uploaded to the
221 webserver. See the Section "Updating the webserver" in this
227 The <i class="CITETITLE">User Manual</i> is also used for
228 context sensitive help for the CGI editor. This is version
229 sensitive, so that the user will get appropriate help for
230 his/her release. So with each release a fresh version should be
231 uploaded to the webserver (this is in addition to the main <i
232 class="CITETITLE">User Manual</i> link from the main page since
233 we need to keep manuals for various versions available). The
234 CGI pages will link to something like <tt class=
235 "LITERAL">http://privoxy.org/$(VERSION)/user-manual/</tt>. This
236 will need to be updated for each new release. There is no
237 Makefile target for this at this time!!! It needs to be done
243 All developers should look at the <tt class=
244 "FILENAME">ChangeLog</tt> and make sure noteworthy changes are
250 <span class="emphasis"><i class="EMPHASIS">Commit all files
251 that were changed in the above steps!</i></span>
256 Tag all files in CVS with the version number with <span class=
257 "QUOTE">"<b class="COMMAND">cvs tag v_X_Y_Z</b>"</span>. Don't
258 use vX_Y_Z, ver_X_Y_Z, v_X.Y.Z (won't work) etc.
263 If the release was in a development branch, increase the point
264 version from even to odd (X.Y.(Z+1)) again in <tt class=
265 "FILENAME">configure.in</tt> and commit your change.
270 On the webserver, copy the user manual to a new top-level
271 directory called <tt class="FILENAME">X.Y.Z</tt>. This ensures
272 that help links from the CGI pages, which have the version as a
273 prefix, will go into the right version of the manual. If this
274 is a development branch release, also symlink <tt class=
275 "FILENAME">X.Y.(Z-1)</tt> to <tt class="FILENAME">X.Y.Z</tt>
276 and <tt class="FILENAME">X.Y.(Z+1)</tt> to <tt class=
277 "FILENAME">.</tt> (i.e. dot).
284 <a name="THERELEASE">6.3. Building and Releasing the Packages</a>
287 Now the individual packages can be built and released. Note that
288 for GPL reasons the first package to be released is always the
292 For <span class="emphasis"><i class="EMPHASIS">all</i></span> types
293 of packages, including the source tarball, <span class=
294 "emphasis"><i class="EMPHASIS">you must make sure that you build
295 from clean sources by exporting the right version from CVS into an
296 empty directory</i></span> (just press return when asked for a
301 <table border="0" bgcolor="#E0E0E0" width="100%">
304 <pre class="PROGRAMLISTING">
305 mkdir dist # delete or choose different name if it already exists
307 cvs -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa login
308 cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa export -r v_X_Y_Z current
315 <span class="emphasis"><i class="EMPHASIS">Do NOT change</i></span>
316 a single bit, including, but not limited to version information
317 after export from CVS. This is to make sure that all release
318 packages, and with them, all future bug reports, are based on
319 exactly the same code.
321 <div class="WARNING">
322 <table class="WARNING" border="1" width="100%">
331 Every significant release of Privoxy has included at least
332 one package that either had incorrect versions of files,
333 missing files, or incidental leftovers from a previous
334 build process that gave unknown numbers of users headaches
335 to try to figure out what was wrong. PLEASE, make sure you
336 are using pristene sources, and are following the
344 Please find additional instructions for the source tarball and the
345 individual platform dependent binary packages below. And details on
346 the Sourceforge release process below that.
350 <a name="PACK-GUIDELINES">6.3.1. Note on Privoxy Packaging</a>
353 Please keep these general guidelines in mind when putting
354 together your package. These apply to <span class="emphasis"><i
355 class="EMPHASIS">all</i></span> platforms!
362 <span class="APPLICATION">Privoxy</span> <span class=
363 "emphasis"><i class="EMPHASIS">requires</i></span> write
364 access to: all <tt class="FILENAME">*.action</tt> files, all
365 logfiles, and the <tt class="FILENAME">trust</tt> file. You
366 will need to determine the best way to do this for your
372 Please include up to date documentation. At a bare minimum:
378 <tt class="FILENAME">LICENSE</tt> (top-level directory)
387 <tt class="FILENAME">README</tt> (top-level directory)
396 <tt class="FILENAME">AUTHORS</tt> (top-level directory)
405 <tt class="FILENAME">man page</tt> (top-level
406 directory, Unix-like platforms only)
415 <tt class="FILENAME">The User Manual</tt>
416 (doc/webserver/user-manual/)
425 <tt class="FILENAME">FAQ</tt> (doc/webserver/faq/)
431 Also suggested: <tt class="FILENAME">Developer Manual</tt>
432 (doc/webserver/developer-manual) and <tt class=
433 "FILENAME">ChangeLog</tt> (top-level directory). <tt class=
434 "FILENAME">FAQ</tt> and the manuals are HTML docs. There are
435 also text versions in <tt class="FILENAME">doc/text/</tt>
436 which could conceivably also be included.
439 The documentation has been designed such that the manuals are
440 linked to each other from parallel directories, and should be
441 packaged that way. <tt class=
442 "FILENAME">privoxy-index.html</tt> can also be included and
443 can serve as a focal point for docs and other links of
444 interest (and possibly renamed to <tt class=
445 "FILENAME">index.html</tt>). This should be one level up from
446 the manuals. There is a link also on this page to an HTMLized
447 version of the man page. To avoid 404 for this, it is in CVS
449 "FILENAME">doc/webserver/man-page/privoxy-man-page.html</tt>,
450 and should be included along with the manuals. There is also
451 a css stylesheets that can be included for better
452 presentation: <tt class="FILENAME">p_doc.css</tt>. This
453 should be in the same directory with <tt class=
454 "FILENAME">privoxy-index.html</tt>, (i.e. one level up from
455 the manual directories).
460 <tt class="FILENAME">user.action</tt> and <tt class=
461 "FILENAME">user.filter</tt> are designed for local
462 preferences. Make sure these do not get overwritten! <tt
463 class="FILENAME">config</tt> should not be overwritten
464 either. This has especially important configuration data in
465 it. <tt class="FILENAME">trust</tt> should be left in tact as
471 Other configuration files (<tt class=
472 "FILENAME">default.action</tt> and <tt class=
473 "FILENAME">default.filter</tt>) should be installed as the
474 new defaults, but all previously installed configuration
475 files should be preserved as backups. This is just good
476 manners :-) These files are likely to change between releases
477 and contain important new features and bug fixes.
482 Please check platform specific notes in this doc, if you
483 haven't done <span class="QUOTE">"Privoxy"</span> packaging
484 before for other platform specific issues. Conversely, please
485 add any notes that you know are important for your platform
486 (or contact one of the doc maintainers to do this if you
492 Packagers should do a <span class="QUOTE">"clean"</span>
493 install of their package after building it. So any previous
494 installs should be removed first to ensure the integrity of
495 the newly built package. Then run the package for a while to
496 make sure there are no obvious problems, before uploading.
503 <a name="NEWRELEASE-TARBALL">6.3.2. Source Tarball</a>
506 First, <span class="emphasis"><i class="EMPHASIS">make sure that
507 you have freshly exported the right version into an empty
508 directory</i></span>. (See "Building and releasing packages"
513 <table border="0" bgcolor="#E0E0E0" width="100%">
516 <pre class="PROGRAMLISTING">
518 autoheader && autoconf && ./configure
529 <table border="0" bgcolor="#E0E0E0" width="100%">
532 <pre class="PROGRAMLISTING">
540 To upload the package to Sourceforge, simply issue
544 <table border="0" bgcolor="#E0E0E0" width="100%">
547 <pre class="PROGRAMLISTING">
555 Go to the displayed URL and release the file publicly on
556 Sourceforge. For the change log field, use the relevant section
557 of the <tt class="FILENAME">ChangeLog</tt> file.
562 <a name="NEWRELEASE-RPM">6.3.3. SuSE, Conectiva or Red Hat
566 In following text, replace <tt class=
567 "REPLACEABLE"><i>dist</i></tt> with either <span class=
568 "QUOTE">"rh"</span> for Red Hat or <span class=
569 "QUOTE">"suse"</span> for SuSE.
572 First, <span class="emphasis"><i class="EMPHASIS">make sure that
573 you have freshly exported the right version into an empty
574 directory</i></span>. (See "Building and releasing packages"
578 As the only exception to not changing anything after export from
579 CVS, now examine the file <tt class="FILENAME">privoxy-</tt><tt
580 class="REPLACEABLE"><i>dist</i></tt><tt class=
581 "FILENAME">.spec</tt> and make sure that the version information
582 and the RPM release number are correct. The RPM release numbers
583 for each version start at one. Hence it must be reset to one if
584 this is the first RPM for <tt class=
585 "REPLACEABLE"><i>dist</i></tt> which is built from version X.Y.Z.
587 "https://sourceforge.net/project/showfiles.php?group_id=11118"
588 target="_top">file list</a> if unsure. Else, it must be set to
589 the highest already available RPM release number for that version
597 <table border="0" bgcolor="#E0E0E0" width="100%">
600 <pre class="PROGRAMLISTING">
602 autoheader && autoconf && ./configure
613 <table border="0" bgcolor="#E0E0E0" width="100%">
616 <pre class="PROGRAMLISTING">
617 make <tt class="REPLACEABLE"><i>dist</i></tt>-dist
624 To upload the package to Sourceforge, simply issue
628 <table border="0" bgcolor="#E0E0E0" width="100%">
631 <pre class="PROGRAMLISTING">
632 make <tt class="REPLACEABLE"><i>dist</i></tt>-upload <tt class=
633 "REPLACEABLE"><i>rpm_packagerev</i></tt>
640 where <tt class="REPLACEABLE"><i>rpm_packagerev</i></tt> is the
641 RPM release number as determined above. Go to the displayed URL
642 and release the file publicly on Sourceforge. Use the release
643 notes and change log from the source tarball package.
648 <a name="NEWRELEASE-OS2">6.3.4. OS/2</a>
651 First, <span class="emphasis"><i class="EMPHASIS">make sure that
652 you have freshly exported the right version into an empty
653 directory</i></span>. (See "Building and releasing packages"
654 above). Then get the OS/2 Setup module:
658 <table border="0" bgcolor="#E0E0E0" width="100%">
661 <pre class="PROGRAMLISTING">
662 cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co os2setup
669 You will need a mix of development tools. The main compilation
670 takes place with IBM Visual Age C++. Some ancillary work takes
671 place with GNU tools, available from various sources like
672 hobbes.nmsu.edu. Specificially, you will need <tt class=
673 "FILENAME">autoheader</tt>, <tt class="FILENAME">autoconf</tt>
674 and <tt class="FILENAME">sh</tt> tools. The packaging takes place
675 with WarpIN, available from various sources, including its home
676 page: <a href="http://www.xworkplace.org/" target=
677 "_top">xworkplace</a>.
680 Change directory to the <tt class="FILENAME">os2setup</tt>
681 directory. Edit the os2build.cmd file to set the final executable
682 filename. For example,
686 <table border="0" bgcolor="#E0E0E0" width="100%">
689 <pre class="PROGRAMLISTING">
690 installExeName='privoxyos2_setup_X.Y.Z.exe'
697 Next, edit the <tt class="FILENAME">IJB.wis</tt> file so the
698 release number matches in the <tt class="FILENAME">PACKAGEID</tt>
703 <table border="0" bgcolor="#E0E0E0" width="100%">
706 <pre class="PROGRAMLISTING">
707 PACKAGEID="Privoxy Team\Privoxy\Privoxy Package\X\Y\Z"
714 You're now ready to build. Run:
718 <table border="0" bgcolor="#E0E0E0" width="100%">
721 <pre class="PROGRAMLISTING">
729 You will find the WarpIN-installable executable in the <tt class=
730 "FILENAME">./files</tt> directory. Upload this anonymously to <tt
731 class="FILENAME">uploads.sourceforge.net/incoming</tt>, create a
732 release for it, and you're done. Use the release notes and Change
733 Log from the source tarball package.
738 <a name="NEWRELEASE-SOLARIS">6.3.5. Solaris</a>
741 Login to Sourceforge's compilefarm via ssh:
745 <table border="0" bgcolor="#E0E0E0" width="100%">
748 <pre class="PROGRAMLISTING">
749 ssh cf.sourceforge.net
756 Choose the right operating system (not the Debian one). When
757 logged in, <span class="emphasis"><i class="EMPHASIS">make sure
758 that you have freshly exported the right version into an empty
759 directory</i></span>. (See "Building and releasing packages"
764 <table border="0" bgcolor="#E0E0E0" width="100%">
767 <pre class="PROGRAMLISTING">
769 autoheader && autoconf && ./configure
780 <table border="0" bgcolor="#E0E0E0" width="100%">
783 <pre class="PROGRAMLISTING">
791 which creates a gzip'ed tar archive. Sadly, you cannot use <b
792 class="COMMAND">make solaris-upload</b> on the Sourceforge
793 machine (no ncftpput). You now have to manually upload the
794 archive to Sourceforge's ftp server and release the file
795 publicly. Use the release notes and Change Log from the source
801 <a name="NEWRELEASE-WINDOWS">6.3.6. Windows</a>
805 "http://www.fruitbat.org/Cygwin/index.html#cygwincirca" target=
806 "_top">Cygwin Time Machine</a> to install the last 1.5 version of
807 Cygwin. Run the following commands from within the Cygwin 1.5
811 First, <span class="emphasis"><i class="EMPHASIS">make sure that
812 you have freshly exported the right version into an empty
813 directory</i></span>. (See "Building and releasing packages"
814 above). Then get the Windows setup module:
818 <table border="0" bgcolor="#E0E0E0" width="100%">
821 <pre class="PROGRAMLISTING">
822 cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co winsetup
829 Then you can build the package. This is fully automated, and is
830 controlled by <tt class="FILENAME">winsetup/GNUmakefile</tt>. All
835 <table border="0" bgcolor="#E0E0E0" width="100%">
838 <pre class="PROGRAMLISTING">
847 Now you can manually rename <tt class=
848 "FILENAME">privoxy_setup.exe</tt> to <tt class=
849 "FILENAME">privoxy_setup_X_Y_Z.exe</tt>, and upload it to
850 SourceForge. When releasing the package on SourceForge, use the
851 release notes and Change Log from the source tarball package.
856 <a name="NEWRELEASE-DEBIAN">6.3.7. Debian</a>
859 First, <span class="emphasis"><i class="EMPHASIS">make sure that
860 you have freshly exported the right version into an empty
861 directory</i></span>. (See "Building and releasing packages"
862 above). Then add a log entry to <tt class=
863 "FILENAME">debian/changelog</tt>, if it is not already there, for
868 <table border="0" bgcolor="#E0E0E0" width="100%">
871 <pre class="PROGRAMLISTING">
872 debchange -v 3.0.26-UNRELEASED-1 "New upstream version"
883 <table border="0" bgcolor="#E0E0E0" width="100%">
886 <pre class="PROGRAMLISTING">
887 dpkg-buildpackage -rfakeroot -us -uc -b
894 This will create <tt class=
895 "FILENAME">../privoxy_3.0.26-UNRELEASED-1_i386.deb</tt> which can
896 be uploaded. To upload the package to Sourceforge, simply issue
900 <table border="0" bgcolor="#E0E0E0" width="100%">
903 <pre class="PROGRAMLISTING">
912 <a name="NEWRELEASE-MACOSX">6.3.8. Mac OS X</a>
915 First, <span class="emphasis"><i class="EMPHASIS">make sure that
916 you have freshly exported the right version into an empty
917 directory</i></span>. (See "Building and releasing packages"
921 There are three modules available in the CVS repository for use
922 on Mac OS X, though technically only two of them generate a
923 release (the other can be used to install from source).
927 <a name="OS-X-OSXPACKAGEBUILDER-MODULE">6.3.8.1.
928 OSXPackageBuilder module</a>
931 The OSXPackageBuilder module generates OS X installer packages
932 supporting all Macs running OS X 10.4 and above. Obtain it from
933 CVS as follows into a folder parallel to the exported privoxy
936 <table border="0" bgcolor="#E0E0E0" width="100%">
939 <pre class="PROGRAMLISTING">
940 cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co OSXPackageBuilder
947 The module contains complete instructions on its usage in the
948 file <tt class="FILENAME">OS X Package Builder HOWTO.txt</tt>.
951 Once the package(s) have been generated, you can then upload
952 them directly to the Files section of the Sourceforge project
953 in the Macintosh (OS X) folder. Each new version release of
954 Privoxy should have a new subfolder created in which to store
955 its files. Please ensure that the folder contains a readme file
956 that makes it clear which package is for whichversion of OS X.
961 <a name="OS-X-OSXSETUP-MODULE">6.3.8.2. osxsetup module
965 <span class="emphasis"><i class="EMPHASIS">This module is
966 deprecated since the installer it generates places all Privoxy
967 files in one folder in a non-standard location, and supports
968 only Intel Macs running OS X 10.6 or higher.</i></span>
971 Check out the module from CVS as follows into a folder parallel
972 to the exported privoxy source:
974 <table border="0" bgcolor="#E0E0E0" width="100%">
977 <pre class="PROGRAMLISTING">
978 cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co osxsetup
989 <table border="0" bgcolor="#E0E0E0" width="100%">
992 <pre class="PROGRAMLISTING">
1001 This will run <tt class="FILENAME">autoheader</tt>, <tt class=
1002 "FILENAME">autoconf</tt> and <tt class=
1003 "FILENAME">configure</tt> as well as <tt class=
1004 "FILENAME">make</tt>. Finally, it will copy over the necessary
1005 files to the ./osxsetup/files directory for further processing
1006 by <tt class="FILENAME">PackageMaker</tt>.
1009 Bring up PackageMaker with the PrivoxyPackage.pmsp definition
1010 file, modify the package name to match the release, and hit the
1011 "Create package" button. If you specify ./Privoxy.pkg as the
1012 output package name, you can then create the distributable zip
1013 file with the command:
1017 <table border="0" bgcolor="#E0E0E0" width="100%">
1020 <pre class="PROGRAMLISTING">
1021 zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg
1028 You can then upload this file directly to the Files section of
1029 the Sourceforge project in the Macintosh (OS X) folder. Each
1030 new version release of Privoxy should have a new subfolder
1031 created in which to store its files. Please ensure that the
1032 folder contains a readme file that makes it clear which
1033 version(s) of OS X the package supports.
1038 <a name="OS-X-MACSETUP-MODULE">6.3.8.3. macsetup module</a>
1041 The macsetup module is ideal if you wish to build and install
1042 Privoxy from source on a single machine.
1045 Check out the module from CVS as follows into a folder parallel
1046 to the exported privoxy source:
1048 <table border="0" bgcolor="#E0E0E0" width="100%">
1051 <pre class="PROGRAMLISTING">
1052 cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co macsetup
1059 The module contains complete instructions on its usage in its
1060 <tt class="FILENAME">README</tt> file. The end result will be
1061 the exported version of Privoxy installed on the build machine.
1067 <a name="NEWRELEASE-FREEBSD">6.3.9. FreeBSD</a>
1070 Update the www/privoxy port and submit a diff upstream. For
1071 details see the <a href=
1072 "https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/"
1073 target="_top">FreeBSD Porter's Handbook</a>.
1079 <a name="RELEASING">6.4. Uploading and Releasing Your Package</a>
1082 After the package is ready, it is time to upload it to SourceForge,
1083 and go through the release steps. The upload is done via FTP:
1090 Upload to: <a href="ftp://upload.sourceforge.net/incoming"
1091 target="_top">ftp://upload.sourceforge.net/incoming</a>
1096 user: <tt class="LITERAL">anonymous</tt>
1101 password: <tt class=
1102 "LITERAL">ijbswa-developers@lists.sourceforge.net</tt>
1108 Or use the <b class="COMMAND">make</b> targets as described above.
1111 Once this done go to <a href=
1112 "https://sourceforge.net/project/admin/editpackages.php?group_id=11118"
1114 "_top">https://sourceforge.net/project/admin/editpackages.php?group_id=11118</a>,
1115 making sure you are logged in. Find your target platform in the
1116 second column, and click <tt class="LITERAL">Add Release</tt>. You
1117 will then need to create a new release for your package, using the
1118 format of <tt class="LITERAL">$VERSION ($CODE_STATUS)</tt>, e.g.
1119 <span class="emphasis"><i class="EMPHASIS">3.0.26
1123 Now just follow the prompts. Be sure to add any appropriate Release
1124 notes. You should see your freshly uploaded packages in <span
1125 class="QUOTE">"Step 2. Add Files To This Release"</span>. Check the
1126 appropriate box(es). Remember at each step to hit the <span class=
1127 "QUOTE">"Refresh/Submit"</span> buttons! You should now see your
1128 file(s) listed in Step 3. Fill out the forms with the appropriate
1129 information for your platform, being sure to hit <span class=
1130 "QUOTE">"Update"</span> for each file. If anyone is monitoring your
1131 platform, check the <span class="QUOTE">"email"</span> box at the
1132 very bottom to notify them of the new package. This should do it!
1135 If you have made errors, or need to make changes, you can go
1136 through essentially the same steps, but select <tt class=
1137 "LITERAL">Edit Release</tt>, instead of <tt class="LITERAL">Add
1143 <a name="AFTERRELEASE">6.5. After the Release</a>
1146 When all (or: most of the) packages have been uploaded and made
1147 available, send an email to the <a href=
1148 "mailto:privoxy-announce@lists.privoxy.org" target="_top">announce
1149 mailing list</a>, Subject: "Version X.Y.Z available for download".
1150 Be sure to include the <a href=
1151 "https://sourceforge.net/project/showfiles.php?group_id=11118"
1152 target="_top">download location</a>, the release notes and the
1153 Changelog. Also, post an updated News item on the project page
1154 Sourceforge, and update the Home page and docs linked from the Home
1155 page (see below). Other news sites and release oriented sites, such
1156 as Freshmeat, should also be notified.
1160 <div class="NAVFOOTER">
1161 <hr align="LEFT" width="100%">
1162 <table summary="Footer navigation table" width="100%" border="0"
1163 cellpadding="0" cellspacing="0">
1165 <td width="33%" align="left" valign="top">
1166 <a href="testing.html" accesskey="P">Prev</a>
1168 <td width="34%" align="center" valign="top">
1169 <a href="index.html" accesskey="H">Home</a>
1171 <td width="33%" align="right" valign="top">
1172 <a href="webserver-update.html" accesskey="N">Next</a>
1176 <td width="33%" align="left" valign="top">
1179 <td width="34%" align="center" valign="top">
1182 <td width="33%" align="right" valign="top">
1183 Update the Webserver