1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
2 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
5 <meta name="generator" content="HTML Tidy, see www.w3.org">
7 Releasing a New Version
9 <meta name="GENERATOR" content=
10 "Modular DocBook HTML Stylesheet Version 1.79">
11 <link rel="HOME" title="Privoxy Developer Manual" href="index.html">
12 <link rel="PREVIOUS" title="Testing Guidelines" href="testing.html">
13 <link rel="NEXT" title="Update the Webserver" href=
14 "webserver-update.html">
15 <link rel="STYLESHEET" type="text/css" href="../p_doc.css">
16 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
17 <style type="text/css">
19 background-color: #EEEEEE;
22 :link { color: #0000FF }
23 :visited { color: #840084 }
24 :active { color: #0000FF }
25 hr.c1 {text-align: left}
29 <div class="NAVHEADER">
30 <table summary="Header navigation table" width="100%" border="0"
31 cellpadding="0" cellspacing="0">
33 <th colspan="3" align="center">
34 Privoxy Developer Manual
38 <td width="10%" align="left" valign="bottom">
39 <a href="testing.html" accesskey="P">Prev</a>
41 <td width="80%" align="center" valign="bottom">
43 <td width="10%" align="right" valign="bottom">
44 <a href="webserver-update.html" accesskey="N">Next</a>
48 <hr width="100%" class="c1">
52 <a name="NEWRELEASE">6. Releasing a New Version</a>
55 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,
58 so it is very important that great care is taken to ensure that
59 everything runs fine, and not to introduce problems in the very last
63 So when releasing a new version, please adhere exactly to the
64 procedure outlined in this chapter.
67 The following programs are required to follow this process: <tt
68 class="FILENAME">ncftpput</tt> (ncftp), <tt class="FILENAME">scp,
69 ssh</tt> (ssh), <tt class="FILENAME">gmake</tt> (GNU's version of
74 <a name="VERSIONNUMBERS">6.1. Version numbers</a>
77 First you need to determine which version number the release will
78 have. <span class="APPLICATION">Privoxy</span> version numbers
79 consist of three numbers, separated by dots, like in X.Y.Z (e.g.
85 X, the version major, is rarely ever changed. It is increased
86 by one if turning a development branch into stable
87 substantially changes the functionality, user interface or
88 configuration syntax. Majors 1 and 2 were <span class=
89 "APPLICATION">Junkbuster</span>, and 3 will be the first stable
90 <span class="APPLICATION">Privoxy</span> release.
95 Y, the version minor, represents the branch within the major
96 version. At any point in time, there are two branches being
97 maintained: The stable branch, with an even minor, say, 2N, in
98 which no functionality is being added and only bug-fixes are
99 made, and 2N+1, the development branch, in which the further
100 development of <span class="APPLICATION">Privoxy</span> takes
101 place. This enables us to turn the code upside down and inside
102 out, while at the same time providing and maintaining a stable
103 version. The minor is reset to zero (and one) when the major is
104 incremented. When a development branch has matured to the point
105 where it can be turned into stable, the old stable branch 2N is
106 given up (i.e. no longer maintained), the former development
107 branch 2N+1 becomes the new stable branch 2N+2, and a new
108 development branch 2N+3 is opened.
113 Z, the point or sub version, represents a release of the
114 software within a branch. It is therefore incremented
115 immediately before each code freeze. In development branches,
116 only the even point versions correspond to actual releases,
117 while the odd ones denote the evolving state of the sources on
118 CVS in between. It follows that Z is odd on CVS in development
119 branches most of the time. There, it gets increased to an even
120 number immediately before a code freeze, and is increased to an
121 odd number again immediately thereafter. This ensures that
122 builds from CVS snapshots are easily distinguished from
123 released versions. The point version is reset to zero when the
127 Stable branches work a little differently, since there should
128 be little to no development happening in such branches.
129 Remember, only bugfixes, which presumably should have had some
130 testing before being committed. Stable branches will then have
131 their version reported as <tt class="LITERAL">0.0.0</tt>,
132 during that period between releases when changes are being
133 added. This is to denote that this code is <span class=
134 "emphasis"><i class="EMPHASIS">not for release</i></span>. Then
135 as the release nears, the version is bumped according: e.g. <tt
136 class="LITERAL">3.0.1 -> 0.0.0 -> 3.0.2</tt>.
142 In summary, the main CVS trunk is the development branch where new
143 features are being worked on for the next stable series. This
144 should almost always be where the most activity takes place. There
145 is always at least one stable branch from the trunk, e.g now it is
146 <tt class="LITERAL">3.0</tt>, which is only used to release stable
147 versions. Once the initial *.0 release of the stable branch has
148 been done, then as a rule, only bugfixes that have had prior
149 testing should be committed to the stable branch. Once there are
150 enough bugfixes to justify a new release, the version of this
151 branch is again incremented Example: 3.0.0 -> 3.0.1 -> 3.0.2,
152 etc are all stable releases from within the stable branch. 3.1.x is
153 currently the main trunk, and where work on 3.2.x is taking place.
154 If any questions, please post to the devel list <span class=
155 "emphasis"><i class="EMPHASIS">before</i></span> committing to a
159 Developers should remember too that if they commit a bugfix to the
160 stable branch, this will more than likely require a separate
161 submission to the main trunk, since these are separate development
162 trees within CVS. If you are working on both, then this would
163 require at least two separate check outs (i.e main trunk, <span
164 class="emphasis"><i class="EMPHASIS">and</i></span> the stable
165 release branch, which is <tt class="LITERAL">v_3_0_branch</tt> at
171 <a name="BEFORERELEASE">6.2. Before the Release: Freeze</a>
174 The following <span class="emphasis"><i class="EMPHASIS">must be
175 done by one of the developers</i></span> prior to each new release.
182 Make sure that everybody who has worked on the code in the last
183 couple of days has had a chance to yell <span class=
184 "QUOTE">"no!"</span> in case they have pending changes/fixes in
185 their pipelines. Announce the freeze so that nobody will
186 interfere with last minute changes.
191 Increment the version number (point from odd to even in
192 development branches!) in <tt class=
193 "FILENAME">configure.in</tt>. (RPM spec files will need to be
194 incremented as well.)
199 If <tt class="FILENAME">default.action</tt> has changed since
200 last release (i.e. software release or standalone actions file
201 release), bump up its version info to A.B in this line:
205 <table border="0" bgcolor="#E0E0E0" width="90%">
208 <pre class="PROGRAMLISTING">
209 {+add-header{X-Actions-File-Version: A.B} -filter -no-popups}
216 Then change the version info in
217 doc/webserver/actions/index.php, line:
218 '$required_actions_file_version = "A.B";'
223 All documentation should be rebuild after the version bump.
224 Finished docs should be then be committed to CVS (for those
225 without the ability to build these). Some docs may require
226 rather obscure processing tools. <tt class=
227 "FILENAME">config</tt>, the man page (and the html version of
228 the man page), and the PDF docs fall in this category. REAMDE,
229 the man page, AUTHORS, and config should all also be committed
230 to CVS for other packagers. The formal docs should be uploaded
231 to the webserver. See the Section "Updating the webserver" in
232 this manual for details.
237 The <i class="CITETITLE">User Manual</i> is also used for
238 context sensitive help for the CGI editor. This is version
239 sensitive, so that the user will get appropriate help for
240 his/her release. So with each release a fresh version should be
241 uploaded to the webserver (this is in addition to the main <i
242 class="CITETITLE">User Manual</i> link from the main page since
243 we need to keep manuals for various versions available). The
244 CGI pages will link to something like <tt class=
245 "LITERAL">http://privoxy.org/$(VERSION)/user-manual/</tt>. This
246 will need to be updated for each new release. There is no
247 Makefile target for this at this time!!! It needs to be done
253 All developers should look at the <tt class=
254 "FILENAME">ChangeLog</tt> and make sure noteworthy changes are
260 <span class="emphasis"><i class="EMPHASIS">Commit all files
261 that were changed in the above steps!</i></span>
266 Tag all files in CVS with the version number with <span class=
267 "QUOTE">"<b class="COMMAND">cvs tag v_X_Y_Z</b>"</span>. Don't
268 use vX_Y_Z, ver_X_Y_Z, v_X.Y.Z (won't work) etc.
273 If the release was in a development branch, increase the point
274 version from even to odd (X.Y.(Z+1)) again in <tt class=
275 "FILENAME">configure.in</tt> and commit your change.
280 On the webserver, copy the user manual to a new top-level
281 directory called <tt class="FILENAME">X.Y.Z</tt>. This ensures
282 that help links from the CGI pages, which have the version as a
283 prefix, will go into the right version of the manual. If this
284 is a development branch release, also symlink <tt class=
285 "FILENAME">X.Y.(Z-1)</tt> to <tt class="FILENAME">X.Y.Z</tt>
286 and <tt class="FILENAME">X.Y.(Z+1)</tt> to <tt class=
287 "FILENAME">.</tt> (i.e. dot).
294 <a name="THERELEASE">6.3. Building and Releasing the Packages</a>
297 Now the individual packages can be built and released. Note that
298 for GPL reasons the first package to be released is always the
302 For <span class="emphasis"><i class="EMPHASIS">all</i></span> types
303 of packages, including the source tarball, <span class=
304 "emphasis"><i class="EMPHASIS">you must make sure that you build
305 from clean sources by exporting the right version from CVS into an
306 empty directory</i></span> (just press return when asked for a
311 <table border="0" bgcolor="#E0E0E0" width="100%">
314 <pre class="PROGRAMLISTING">
315 mkdir dist # delete or choose different name if it already exists
317 cvs -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa login
318 cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa export -r v_X_Y_Z current
325 <span class="emphasis"><i class="EMPHASIS">Do NOT change</i></span>
326 a single bit, including, but not limited to version information
327 after export from CVS. This is to make sure that all release
328 packages, and with them, all future bug reports, are based on
329 exactly the same code.
331 <div class="WARNING">
332 <table class="WARNING" border="1" width="100%">
341 Every significant release of Privoxy has included at least
342 one package that either had incorrect versions of files,
343 missing files, or incidental leftovers from a previous
344 build process that gave unknown numbers of users headaches
345 to try to figure out what was wrong. PLEASE, make sure you
346 are using pristene sources, and are following the
354 Please find additional instructions for the source tarball and the
355 individual platform dependent binary packages below. And details on
356 the Sourceforge release process below that.
360 <a name="PACK-GUIDELINES">6.3.1. Note on Privoxy Packaging</a>
363 Please keep these general guidelines in mind when putting
364 together your package. These apply to <span class="emphasis"><i
365 class="EMPHASIS">all</i></span> platforms!
372 <span class="APPLICATION">Privoxy</span> <span class=
373 "emphasis"><i class="EMPHASIS">requires</i></span> write
374 access to: all <tt class="FILENAME">*.action</tt> files, all
375 logfiles, and the <tt class="FILENAME">trust</tt> file. You
376 will need to determine the best way to do this for your
382 Please include up to date documentation. At a bare minimum:
388 <tt class="FILENAME">LICENSE</tt> (top-level directory)
397 <tt class="FILENAME">README</tt> (top-level directory)
406 <tt class="FILENAME">AUTHORS</tt> (top-level directory)
415 <tt class="FILENAME">man page</tt> (top-level
416 directory, Unix-like platforms only)
425 <tt class="FILENAME">The User Manual</tt>
426 (doc/webserver/user-manual/)
435 <tt class="FILENAME">FAQ</tt> (doc/webserver/faq/)
441 Also suggested: <tt class="FILENAME">Developer Manual</tt>
442 (doc/webserver/developer-manual) and <tt class=
443 "FILENAME">ChangeLog</tt> (top-level directory). <tt class=
444 "FILENAME">FAQ</tt> and the manuals are HTML docs. There are
445 also text versions in <tt class="FILENAME">doc/text/</tt>
446 which could conceivably also be included.
449 The documentation has been designed such that the manuals are
450 linked to each other from parallel directories, and should be
451 packaged that way. <tt class=
452 "FILENAME">privoxy-index.html</tt> can also be included and
453 can serve as a focal point for docs and other links of
454 interest (and possibly renamed to <tt class=
455 "FILENAME">index.html</tt>). This should be one level up from
456 the manuals. There is a link also on this page to an HTMLized
457 version of the man page. To avoid 404 for this, it is in CVS
459 "FILENAME">doc/webserver/man-page/privoxy-man-page.html</tt>,
460 and should be included along with the manuals. There is also
461 a css stylesheets that can be included for better
462 presentation: <tt class="FILENAME">p_doc.css</tt>. This
463 should be in the same directory with <tt class=
464 "FILENAME">privoxy-index.html</tt>, (i.e. one level up from
465 the manual directories).
470 <tt class="FILENAME">user.action</tt> and <tt class=
471 "FILENAME">user.filter</tt> are designed for local
472 preferences. Make sure these do not get overwritten! <tt
473 class="FILENAME">config</tt> should not be overwritten
474 either. This has especially important configuration data in
475 it. <tt class="FILENAME">trust</tt> should be left in tact as
481 Other configuration files (<tt class=
482 "FILENAME">default.action</tt> and <tt class=
483 "FILENAME">default.filter</tt>) should be installed as the
484 new defaults, but all previously installed configuration
485 files should be preserved as backups. This is just good
486 manners :-) These files are likely to change between releases
487 and contain important new features and bug fixes.
492 Please check platform specific notes in this doc, if you
493 haven't done <span class="QUOTE">"Privoxy"</span> packaging
494 before for other platform specific issues. Conversely, please
495 add any notes that you know are important for your platform
496 (or contact one of the doc maintainers to do this if you
502 Packagers should do a <span class="QUOTE">"clean"</span>
503 install of their package after building it. So any previous
504 installs should be removed first to ensure the integrity of
505 the newly built package. Then run the package for a while to
506 make sure there are no obvious problems, before uploading.
513 <a name="NEWRELEASE-TARBALL">6.3.2. Source Tarball</a>
516 First, <span class="emphasis"><i class="EMPHASIS">make sure that
517 you have freshly exported the right version into an empty
518 directory</i></span>. (See "Building and releasing packages"
523 <table border="0" bgcolor="#E0E0E0" width="100%">
526 <pre class="PROGRAMLISTING">
528 autoheader && autoconf && ./configure
539 <table border="0" bgcolor="#E0E0E0" width="100%">
542 <pre class="PROGRAMLISTING">
550 To upload the package to Sourceforge, simply issue
554 <table border="0" bgcolor="#E0E0E0" width="100%">
557 <pre class="PROGRAMLISTING">
565 Go to the displayed URL and release the file publicly on
566 Sourceforge. For the change log field, use the relevant section
567 of the <tt class="FILENAME">ChangeLog</tt> file.
572 <a name="NEWRELEASE-RPM">6.3.3. SuSE, Conectiva or Red Hat
576 In following text, replace <tt class=
577 "REPLACEABLE"><i>dist</i></tt> with either <span class=
578 "QUOTE">"rh"</span> for Red Hat or <span class=
579 "QUOTE">"suse"</span> for SuSE.
582 First, <span class="emphasis"><i class="EMPHASIS">make sure that
583 you have freshly exported the right version into an empty
584 directory</i></span>. (See "Building and releasing packages"
588 As the only exception to not changing anything after export from
589 CVS, now examine the file <tt class="FILENAME">privoxy-</tt><tt
590 class="REPLACEABLE"><i>dist</i></tt><tt class=
591 "FILENAME">.spec</tt> and make sure that the version information
592 and the RPM release number are correct. The RPM release numbers
593 for each version start at one. Hence it must be reset to one if
594 this is the first RPM for <tt class=
595 "REPLACEABLE"><i>dist</i></tt> which is built from version X.Y.Z.
597 "http://sourceforge.net/project/showfiles.php?group_id=11118"
598 target="_top">file list</a> if unsure. Else, it must be set to
599 the highest already available RPM release number for that version
607 <table border="0" bgcolor="#E0E0E0" width="100%">
610 <pre class="PROGRAMLISTING">
612 autoheader && autoconf && ./configure
623 <table border="0" bgcolor="#E0E0E0" width="100%">
626 <pre class="PROGRAMLISTING">
627 make <tt class="REPLACEABLE"><i>dist</i></tt>-dist
634 To upload the package to Sourceforge, simply issue
638 <table border="0" bgcolor="#E0E0E0" width="100%">
641 <pre class="PROGRAMLISTING">
642 make <tt class="REPLACEABLE"><i>dist</i></tt>-upload <tt class=
643 "REPLACEABLE"><i>rpm_packagerev</i></tt>
650 where <tt class="REPLACEABLE"><i>rpm_packagerev</i></tt> is the
651 RPM release number as determined above. Go to the displayed URL
652 and release the file publicly on Sourceforge. Use the release
653 notes and change log from the source tarball package.
658 <a name="NEWRELEASE-OS2">6.3.4. OS/2</a>
661 First, <span class="emphasis"><i class="EMPHASIS">make sure that
662 you have freshly exported the right version into an empty
663 directory</i></span>. (See "Building and releasing packages"
664 above). Then get the OS/2 Setup module:
668 <table border="0" bgcolor="#E0E0E0" width="100%">
671 <pre class="PROGRAMLISTING">
672 cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co os2setup
679 You will need a mix of development tools. The main compilation
680 takes place with IBM Visual Age C++. Some ancillary work takes
681 place with GNU tools, available from various sources like
682 hobbes.nmsu.edu. Specificially, you will need <tt class=
683 "FILENAME">autoheader</tt>, <tt class="FILENAME">autoconf</tt>
684 and <tt class="FILENAME">sh</tt> tools. The packaging takes place
685 with WarpIN, available from various sources, including its home
686 page: <a href="http://www.xworkplace.org/" target=
687 "_top">xworkplace</a>.
690 Change directory to the <tt class="FILENAME">os2setup</tt>
691 directory. Edit the os2build.cmd file to set the final executable
692 filename. For example,
696 <table border="0" bgcolor="#E0E0E0" width="100%">
699 <pre class="PROGRAMLISTING">
700 installExeName='privoxyos2_setup_X.Y.Z.exe'
707 Next, edit the <tt class="FILENAME">IJB.wis</tt> file so the
708 release number matches in the <tt class="FILENAME">PACKAGEID</tt>
713 <table border="0" bgcolor="#E0E0E0" width="100%">
716 <pre class="PROGRAMLISTING">
717 PACKAGEID="Privoxy Team\Privoxy\Privoxy Package\X\Y\Z"
724 You're now ready to build. Run:
728 <table border="0" bgcolor="#E0E0E0" width="100%">
731 <pre class="PROGRAMLISTING">
739 You will find the WarpIN-installable executable in the <tt class=
740 "FILENAME">./files</tt> directory. Upload this anonymously to <tt
741 class="FILENAME">uploads.sourceforge.net/incoming</tt>, create a
742 release for it, and you're done. Use the release notes and Change
743 Log from the source tarball package.
748 <a name="NEWRELEASE-SOLARIS">6.3.5. Solaris</a>
751 Login to Sourceforge's compilefarm via ssh:
755 <table border="0" bgcolor="#E0E0E0" width="100%">
758 <pre class="PROGRAMLISTING">
759 ssh cf.sourceforge.net
766 Choose the right operating system (not the Debian one). When
767 logged in, <span class="emphasis"><i class="EMPHASIS">make sure
768 that you have freshly exported the right version into an empty
769 directory</i></span>. (See "Building and releasing packages"
774 <table border="0" bgcolor="#E0E0E0" width="100%">
777 <pre class="PROGRAMLISTING">
779 autoheader && autoconf && ./configure
790 <table border="0" bgcolor="#E0E0E0" width="100%">
793 <pre class="PROGRAMLISTING">
801 which creates a gzip'ed tar archive. Sadly, you cannot use <b
802 class="COMMAND">make solaris-upload</b> on the Sourceforge
803 machine (no ncftpput). You now have to manually upload the
804 archive to Sourceforge's ftp server and release the file
805 publicly. Use the release notes and Change Log from the source
811 <a name="NEWRELEASE-WINDOWS">6.3.6. Windows</a>
814 You should ensure you have the latest version of Cygwin (from <a
815 href="http://www.cygwin.com/" target=
816 "_top">http://www.cygwin.com/</a>). Run the following commands
817 from within a Cygwin bash shell.
820 First, <span class="emphasis"><i class="EMPHASIS">make sure that
821 you have freshly exported the right version into an empty
822 directory</i></span>. (See "Building and releasing packages"
823 above). Then get the Windows setup module:
827 <table border="0" bgcolor="#E0E0E0" width="100%">
830 <pre class="PROGRAMLISTING">
831 cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co winsetup
838 Then you can build the package. This is fully automated, and is
839 controlled by <tt class="FILENAME">winsetup/GNUmakefile</tt>. All
844 <table border="0" bgcolor="#E0E0E0" width="100%">
847 <pre class="PROGRAMLISTING">
856 Now you can manually rename <tt class=
857 "FILENAME">privoxy_setup.exe</tt> to <tt class=
858 "FILENAME">privoxy_setup_X_Y_Z.exe</tt>, and upload it to
859 SourceForge. When releasing the package on SourceForge, use the
860 release notes and Change Log from the source tarball package.
865 <a name="NEWRELEASE-DEBIAN">6.3.7. Debian</a>
868 First, <span class="emphasis"><i class="EMPHASIS">make sure that
869 you have freshly exported the right version into an empty
870 directory</i></span>. (See "Building and releasing packages"
871 above). Then add a log entry to <tt class=
872 "FILENAME">debian/changelog</tt>, if it is not already there, for
877 <table border="0" bgcolor="#E0E0E0" width="100%">
880 <pre class="PROGRAMLISTING">
881 debchange -v 3.0.18-UNRELEASED-1 "New upstream version"
892 <table border="0" bgcolor="#E0E0E0" width="100%">
895 <pre class="PROGRAMLISTING">
896 dpkg-buildpackage -rfakeroot -us -uc -b
903 This will create <tt class=
904 "FILENAME">../privoxy_3.0.18-UNRELEASED-1_i386.deb</tt> which can
905 be uploaded. To upload the package to Sourceforge, simply issue
909 <table border="0" bgcolor="#E0E0E0" width="100%">
912 <pre class="PROGRAMLISTING">
921 <a name="NEWRELEASE-MACOSX">6.3.8. Mac OS X</a>
924 First, <span class="emphasis"><i class="EMPHASIS">make sure that
925 you have freshly exported the right version into an empty
926 directory</i></span>. (See "Building and releasing packages"
927 above). Then get the Mac OS X setup module:
931 <table border="0" bgcolor="#E0E0E0" width="100%">
934 <pre class="PROGRAMLISTING">
935 cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co osxsetup
946 <table border="0" bgcolor="#E0E0E0" width="100%">
949 <pre class="PROGRAMLISTING">
958 This will run <tt class="FILENAME">autoheader</tt>, <tt class=
959 "FILENAME">autoconf</tt> and <tt class="FILENAME">configure</tt>
960 as well as <tt class="FILENAME">make</tt>. Finally, it will copy
961 over the necessary files to the ./osxsetup/files directory for
962 further processing by <tt class="FILENAME">PackageMaker</tt>.
965 Bring up PackageMaker with the PrivoxyPackage.pmsp definition
966 file, modify the package name to match the release, and hit the
967 "Create package" button. If you specify ./Privoxy.pkg as the
968 output package name, you can then create the distributable zip
969 file with the command:
973 <table border="0" bgcolor="#E0E0E0" width="100%">
976 <pre class="PROGRAMLISTING">
977 zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg
984 You can then upload <tt class=
985 "FILENAME">privoxyosx_setup_x.y.z.zip</tt> anonymously to <tt
986 class="FILENAME">uploads.sourceforge.net/incoming</tt>, create a
987 release for it, and you're done. Use the release notes and Change
988 Log from the source tarball package.
993 <a name="NEWRELEASE-FREEBSD">6.3.9. FreeBSD</a>
996 Login to Sourceforge's compile-farm via ssh:
1000 <table border="0" bgcolor="#E0E0E0" width="100%">
1003 <pre class="PROGRAMLISTING">
1004 ssh cf.sourceforge.net
1011 Choose the right operating system. When logged in, <span class=
1012 "emphasis"><i class="EMPHASIS">make sure that you have freshly
1013 exported the right version into an empty directory</i></span>.
1014 (See "Building and releasing packages" above). Then run:
1018 <table border="0" bgcolor="#E0E0E0" width="100%">
1021 <pre class="PROGRAMLISTING">
1023 autoheader && autoconf && ./configure
1034 <table border="0" bgcolor="#E0E0E0" width="100%">
1037 <pre class="PROGRAMLISTING">
1045 which creates a gzip'ed tar archive. Sadly, you cannot use <b
1046 class="COMMAND">make freebsd-upload</b> on the Sourceforge
1047 machine (no ncftpput). You now have to manually upload the
1048 archive to Sourceforge's ftp server and release the file
1049 publicly. Use the release notes and Change Log from the source
1055 <a name="NEWRELEASE-HPUX">6.3.10. HP-UX 11</a>
1058 First, <span class="emphasis"><i class="EMPHASIS">make sure that
1059 you have freshly exported the right version into an empty
1060 directory</i></span>. (See "Building and releasing packages"
1065 <table border="0" bgcolor="#E0E0E0" width="100%">
1068 <pre class="PROGRAMLISTING">
1070 autoheader && autoconf && ./configure
1082 <a name="NEWRELEASE-AMIGA">6.3.11. Amiga OS</a>
1085 First, <span class="emphasis"><i class="EMPHASIS">make sure that
1086 you have freshly exported the right version into an empty
1087 directory</i></span>. (See "Building and releasing packages"
1092 <table border="0" bgcolor="#E0E0E0" width="100%">
1095 <pre class="PROGRAMLISTING">
1097 autoheader && autoconf && ./configure
1109 <a name="NEWRELEASE-AIX">6.3.12. AIX</a>
1112 Login to Sourceforge's compilefarm via ssh:
1116 <table border="0" bgcolor="#E0E0E0" width="100%">
1119 <pre class="PROGRAMLISTING">
1120 ssh cf.sourceforge.net
1127 Choose the right operating system. When logged in, <span class=
1128 "emphasis"><i class="EMPHASIS">make sure that you have freshly
1129 exported the right version into an empty directory</i></span>.
1130 (See "Building and releasing packages" above). Then run:
1134 <table border="0" bgcolor="#E0E0E0" width="100%">
1137 <pre class="PROGRAMLISTING">
1139 autoheader && autoconf && ./configure
1150 <table border="0" bgcolor="#E0E0E0" width="100%">
1153 <pre class="PROGRAMLISTING">
1161 which creates a gzip'ed tar archive. Sadly, you cannot use <b
1162 class="COMMAND">make aix-upload</b> on the Sourceforge machine
1163 (no ncftpput). You now have to manually upload the archive to
1164 Sourceforge's ftp server and release the file publicly. Use the
1165 release notes and Change Log from the source tarball package.
1171 <a name="RELEASING">6.4. Uploading and Releasing Your Package</a>
1174 After the package is ready, it is time to upload it to SourceForge,
1175 and go through the release steps. The upload is done via FTP:
1182 Upload to: <a href="ftp://upload.sourceforge.net/incoming"
1183 target="_top">ftp://upload.sourceforge.net/incoming</a>
1188 user: <tt class="LITERAL">anonymous</tt>
1193 password: <tt class=
1194 "LITERAL">ijbswa-developers@lists.sourceforge.net</tt>
1200 Or use the <b class="COMMAND">make</b> targets as described above.
1203 Once this done go to <a href=
1204 "https://sourceforge.net/project/admin/editpackages.php?group_id=11118"
1206 "_top">https://sourceforge.net/project/admin/editpackages.php?group_id=11118</a>,
1207 making sure you are logged in. Find your target platform in the
1208 second column, and click <tt class="LITERAL">Add Release</tt>. You
1209 will then need to create a new release for your package, using the
1210 format of <tt class="LITERAL">$VERSION ($CODE_STATUS)</tt>, e.g.
1211 <span class="emphasis"><i class="EMPHASIS">3.0.18
1215 Now just follow the prompts. Be sure to add any appropriate Release
1216 notes. You should see your freshly uploaded packages in <span
1217 class="QUOTE">"Step 2. Add Files To This Release"</span>. Check the
1218 appropriate box(es). Remember at each step to hit the <span class=
1219 "QUOTE">"Refresh/Submit"</span> buttons! You should now see your
1220 file(s) listed in Step 3. Fill out the forms with the appropriate
1221 information for your platform, being sure to hit <span class=
1222 "QUOTE">"Update"</span> for each file. If anyone is monitoring your
1223 platform, check the <span class="QUOTE">"email"</span> box at the
1224 very bottom to notify them of the new package. This should do it!
1227 If you have made errors, or need to make changes, you can go
1228 through essentially the same steps, but select <tt class=
1229 "LITERAL">Edit Release</tt>, instead of <tt class="LITERAL">Add
1235 <a name="AFTERRELEASE">6.5. After the Release</a>
1238 When all (or: most of the) packages have been uploaded and made
1239 available, send an email to the <a href=
1240 "mailto:ijbswa-announce@lists.sourceforge.net" target=
1241 "_top">announce mailing list</a>, Subject: "Version X.Y.Z available
1242 for download". Be sure to include the <a href=
1243 "http://sourceforge.net/project/showfiles.php?group_id=11118"
1244 target="_top">download location</a>, the release notes and the
1245 Changelog. Also, post an updated News item on the project page
1246 Sourceforge, and update the Home page and docs linked from the Home
1247 page (see below). Other news sites and release oriented sites, such
1248 as Freshmeat, should also be notified.
1252 <div class="NAVFOOTER">
1253 <hr width="100%" class="c1">
1254 <table summary="Footer navigation table" width="100%" border="0"
1255 cellpadding="0" cellspacing="0">
1257 <td width="33%" align="left" valign="top">
1258 <a href="testing.html" accesskey="P">Prev</a>
1260 <td width="34%" align="center" valign="top">
1261 <a href="index.html" accesskey="H">Home</a>
1263 <td width="33%" align="right" valign="top">
1264 <a href="webserver-update.html" accesskey="N">Next</a>
1268 <td width="33%" align="left" valign="top">
1271 <td width="34%" align="center" valign="top">
1274 <td width="33%" align="right" valign="top">
1275 Update the Webserver