4 >Releasing a New Version</TITLE
7 CONTENT="Modular DocBook HTML Stylesheet Version 1.64
10 TITLE="Privoxy Developer Manual"
11 HREF="index.html"><LINK
13 TITLE="Testing Guidelines"
14 HREF="testing.html"><LINK
16 TITLE="Update the Webserver"
17 HREF="webserver-update.html"><LINK
20 HREF="../p_doc.css"></HEAD
39 >Privoxy Developer Manual</TH
60 HREF="webserver-update.html"
74 >6. Releasing a New Version</A
77 > When we release versions of <SPAN
81 our work leaves our cozy secret lab and has to work in the cold
82 RealWorld[tm]. Once it is released, there is no way to call it
83 back, so it is very important that great care is taken to ensure
84 that everything runs fine, and not to introduce problems in the
88 > So when releasing a new version, please adhere exactly to the
89 procedure outlined in this chapter.
92 > The following programs are required to follow this process:
103 > (GNU's version of make), autoconf, cvs.
110 NAME="VERSIONNUMBERS"
111 >6.1. Version numbers</A
114 > First you need to determine which version number the release will have.
118 > version numbers consist of three numbers,
119 separated by dots, like in X.Y.Z, where:
125 > X, the version major, is rarely ever changed. It is increased by one if
126 turning a development branch into stable substantially changes the functionality,
127 user interface or configuration syntax. Majors 1 and 2 were
131 >, and 3 will be the first stable
140 > Y, the version minor, represents the branch within the major version.
141 At any point in time, there are two branches being maintained:
142 The stable branch, with an even minor, say, 2N, in which no functionality is
143 being added and only bugfixes are made, and 2N+1, the development branch, in
144 which the further development of <SPAN
149 This enables us to turn the code upside down and inside out, while at the same time
150 providing and maintaining a stable version.
151 The minor is reset to zero (and one) when the major is inrcemented. When a development
152 branch has matured to the point where it can be turned into stable, the old stable branch
153 2N is given up (i.e. no longer maintained), the former development branch 2N+1 becomes the
154 new stable branch 2N+2, and a new development branch 2N+3 is opened.
159 > Z, the point or sub version, represents a release of the software within a branch.
160 It is therefore incremented immediately before each code freeze.
161 In development branches, only the even point versions correspond to actual releases,
162 while the odd ones denote the evolving state of the sources on CVS in between.
163 It follows that Z is odd on CVS in development branches most of the time. There, it gets
164 increased to an even number immediately before a code freeze, and is increased to an odd
165 number again immediately thereafter.
166 This ensures that builds from CVS snapshots are easily distinguished from released versions.
167 The point version is reset to zero when the minor changes.
180 >6.2. Before the Release: Freeze</A
185 >must be done by one of the
187 > prior to each new release.
195 > Make sure that everybody who has worked on the code in the last
196 couple of days has had a chance to yell <SPAN
200 they have pending changes/fixes in their pipelines. Announce the
201 freeze so that nobody will interfere with last minute changes.
206 > Increment the version number (point from odd to even in development
218 > has changed since last
219 release (i.e. software release or standalone actions file release),
220 bump up its version info to A.B in this line:
231 CLASS="PROGRAMLISTING"
232 > {+add-header{X-Actions-File-Version: A.B} -filter -no-popups}</PRE
240 Then change the version info in doc/webserver/actions/index.php,
241 line: '$required_actions_file_version = "A.B";'
246 > If the HTML documentation is not in sync with the SGML sources
247 you need to regenerate and upload it to the webserver. (If in
248 doubt, just do it.) See the Section "Updating the webserver" in
249 this manual for details.
256 >Commit all files that were changed in the above steps!</I
262 > Tag all files in CVS with the version number with
270 Don't use vX_Y_Z, ver_X_Y_Z, v_X.Y.Z (won't work) etc.
275 > If the release was in a development branch, increase the point version
276 from even to odd (X.Y.(Z+1)) again in <TT
285 > On the webserver, copy the user manual to a new top-level directory
289 >. This ensures that help links from the CGI
290 pages, which have the version as a prefix, will go into the right version of the manual.
291 If this is a development branch release, also symlink <TT
318 >6.3. Building and Releasing the Packages</A
321 > Now the individual packages can be built and released. Note that for
322 GPL reasons the first package to be released is always the source tarball.
328 > types of packages, including the source tarball,
331 >you must make sure that you build from clean sources by exporting
332 the right version from CVS into an empty directory:</I
343 CLASS="PROGRAMLISTING"
344 > mkdir dist # delete or choose different name if it already exists
346 cvs -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa login
347 cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa export -r v_X_Y_Z current</PRE
357 > a single bit, including, but not limited to
358 version information after export from CVS. This is to make sure that
359 all release packages, and with them, all future bug reports, are based
360 on exactly the same code.
363 > Please find additional instructions for the source tarball and the
364 individual platform dependent binary packages below.
371 NAME="NEWRELEASE-TARBALL"
372 >6.3.1. Source Tarball</A
377 >make sure that you have freshly exported the right
378 version into an empty directory</I
379 >. (See "Building and releasing
380 packages" above). Then run:
390 CLASS="PROGRAMLISTING"
392 autoheader && autoconf && ./configure</PRE
409 CLASS="PROGRAMLISTING"
410 > make tarball-dist</PRE
417 > To upload the package to Sourceforge, simply issue
427 CLASS="PROGRAMLISTING"
428 > make tarball-upload</PRE
435 > Go to the displayed URL and release the file publicly on Sourceforge.
436 For the change log field, use the relevant section of the
448 NAME="NEWRELEASE-RPM"
449 >6.3.2. SuSE or Red Hat RPM</A
452 > In following text, replace <TT
461 > for Red Hat or <SPAN
469 >make sure that you have freshly exported the right
470 version into an empty directory</I
471 >. (See "Building and releasing
475 > As the only exception to not changing anything after export from CVS,
476 now examine the file <TT
488 and make sure that the version information and the RPM release number are
489 correct. The RPM release numbers for each version start at one. Hence it must
490 be reset to one if this is the first RPM for
496 > which is built from version
499 HREF="http://sourceforge.net/project/showfiles.php?group_id=11118"
503 > if unsure. Else, it must be set to the highest already available RPM
504 release number for that version plus one.
517 CLASS="PROGRAMLISTING"
519 autoheader && autoconf && ./configure</PRE
536 CLASS="PROGRAMLISTING"
549 > To upload the package to Sourceforge, simply issue
559 CLASS="PROGRAMLISTING"
583 RPM release number as determined above.
584 Go to the displayed URL and release the file publicly on Sourceforge.
585 Use the release notes and change log from the source tarball package.
593 NAME="NEWRELEASE-OS2"
599 >make sure that you have freshly exported the right
600 version into an empty directory</I
601 >. (See "Building and releasing
602 packages" above). Then get the OS/2 Setup module:
612 CLASS="PROGRAMLISTING"
613 > cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co os2setup</PRE
620 > You will need a mix of development tools.
621 The main compilation takes place with IBM Visual Age C++.
622 Some ancillary work takes place with GNU tools, available from
623 various sources like hobbes.nmsu.edu.
624 Specificially, you will need <TT
635 The packaging takes place with WarpIN, available from various sources, including
637 HREF="http://www.xworkplace.org/"
643 > Change directory to the <TT
647 Edit the os2build.cmd file to set the final executable filename.
658 CLASS="PROGRAMLISTING"
659 > installExeName='privoxyos2_setup_X.Y.Z.exe'</PRE
669 > file so the release number matches
683 CLASS="PROGRAMLISTING"
684 > PACKAGEID="Privoxy Team\Privoxy\Privoxy Package\X\Y\Z"</PRE
691 > You're now ready to build. Run:
701 CLASS="PROGRAMLISTING"
709 > You will find the WarpIN-installable executable in the
713 > directory. Upload this anonymously to
716 >uploads.sourceforge.net/incoming</TT
718 for it, and you're done. Use the release notes and Change Log from the
719 source tarball package.
727 NAME="NEWRELEASE-SOLARIS"
731 > Login to Sourceforge's compilefarm via ssh:
741 CLASS="PROGRAMLISTING"
742 > ssh cf.sourceforge.net</PRE
749 > Choose the right operating system (not the Debian one).
752 >make sure that you have freshly exported the right
753 version into an empty directory</I
754 >. (See "Building and releasing
755 packages" above). Then run:
765 CLASS="PROGRAMLISTING"
767 autoheader && autoconf && ./configure</PRE
784 CLASS="PROGRAMLISTING"
785 > gmake solaris-dist</PRE
792 > which creates a gzip'ed tar archive. Sadly, you cannot use <B
796 > on the Sourceforge machine (no ncftpput). You now have
797 to manually upload the archive to Sourceforge's ftp server and release
798 the file publicly. Use the release notes and Change Log from the
799 source tarball package.
807 NAME="NEWRELEASE-WINDOWS"
811 > You should ensure you have the latest version of Cygwin (from
813 HREF="http://www.cygwin.com/"
815 >http://www.cygwin.com/</A
817 Run the following commands from within a Cygwin bash shell.
822 >make sure that you have freshly exported the right
823 version into an empty directory</I
824 >. (See "Building and releasing
825 packages" above). Then get the Windows setup module:
835 CLASS="PROGRAMLISTING"
836 > cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co winsetup</PRE
843 > Then you can build the package. This is fully automated, and is
846 >winsetup/GNUmakefile</TT
848 All you need to do is:
858 CLASS="PROGRAMLISTING"
867 > Now you can manually rename <TT
869 >privoxy_setup.exe</TT
873 >privoxy_setup_X_Y_Z.exe</TT
875 SourceForge. When releasing the package on SourceForge, use the release notes
876 and Change Log from the source tarball package.
884 NAME="NEWRELEASE-DEBIAN"
890 >make sure that you have freshly exported the right
891 version into an empty directory</I
892 >. (See "Building and releasing
893 packages" above). Then, run:
903 CLASS="PROGRAMLISTING"
905 autoheader && autoconf && ./configure</PRE
920 NAME="NEWRELEASE-MACOSX"
926 >make sure that you have freshly exported the right
927 version into an empty directory</I
928 >. (See "Building and releasing
929 packages" above). Then get the Mac OSX setup module:
939 CLASS="PROGRAMLISTING"
940 > cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co osxsetup</PRE
957 CLASS="PROGRAMLISTING"
980 Finally, it will copy over the necessary files to the ./osxsetup/files directory
981 for further processing by <TT
987 > Bring up PackageMaker with the PrivoxyPackage.pmsp definition file, modify the package
988 name to match the release, and hit the "Create package" button.
989 If you specify ./Privoxy.pkg as the output package name, you can then create
990 the distributable zip file with the command:
1000 CLASS="PROGRAMLISTING"
1001 >zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg</PRE
1008 > You can then upload <TT
1010 >privoxyosx_setup_x.y.z.zip</TT
1014 >uploads.sourceforge.net/incoming</TT
1016 create a release for it, and you're done. Use the release notes
1017 and Change Log from the source tarball package.
1025 NAME="NEWRELEASE-FREEBSD"
1029 > Login to Sourceforge's compilefarm via ssh:
1039 CLASS="PROGRAMLISTING"
1040 > ssh cf.sourceforge.net</PRE
1047 > Choose the right operating system.
1050 >make sure that you have freshly exported the right
1051 version into an empty directory</I
1052 >. (See "Building and releasing
1053 packages" above). Then run:
1063 CLASS="PROGRAMLISTING"
1065 autoheader && autoconf && ./configure</PRE
1082 CLASS="PROGRAMLISTING"
1083 > gmake freebsd-dist</PRE
1090 > which creates a gzip'ed tar archive. Sadly, you cannot use <B
1094 > on the Sourceforge machine (no ncftpput). You now have
1095 to manually upload the archive to Sourceforge's ftp server and release
1096 the file publicly. Use the release notes and Change Log from the
1097 source tarball package.
1105 NAME="NEWRELEASE-HPUX"
1111 >make sure that you have freshly exported the right
1112 version into an empty directory</I
1113 >. (See "Building and releasing
1114 packages" above). Then run:
1124 CLASS="PROGRAMLISTING"
1126 autoheader && autoconf && ./configure</PRE
1141 NAME="NEWRELEASE-AMIGA"
1142 >6.3.10. Amiga OS</A
1147 >make sure that you have freshly exported the right
1148 version into an empty directory</I
1149 >. (See "Building and releasing
1150 packages" above). Then run:
1160 CLASS="PROGRAMLISTING"
1162 autoheader && autoconf && ./configure</PRE
1177 NAME="NEWRELEASE-AIX"
1181 > Login to Sourceforge's compilefarm via ssh:
1191 CLASS="PROGRAMLISTING"
1192 > ssh cf.sourceforge.net</PRE
1199 > Choose the right operating system.
1202 >make sure that you have freshly exported the right
1203 version into an empty directory</I
1204 >. (See "Building and releasing
1205 packages" above). Then run:
1215 CLASS="PROGRAMLISTING"
1217 autoheader && autoconf && ./configure</PRE
1234 CLASS="PROGRAMLISTING"
1235 > make aix-dist</PRE
1242 > which creates a gzip'ed tar archive. Sadly, you cannot use <B
1246 > on the Sourceforge machine (no ncftpput). You now have
1247 to manually upload the archive to Sourceforge's ftp server and release
1248 the file publicly. Use the release notes and Change Log from the
1249 source tarball package.
1259 >6.4. Uploading and Releasing Your Package</A
1262 > After the package is ready, it is time to upload it
1263 to SourceForge, and go through the release steps. The upload
1273 HREF="ftp://upload.sourceforge.net/incoming"
1275 >ftp://upload.sourceforge.net/incoming</A
1291 >ijbswa-developers@lists.sourceforge.net</TT
1299 > Once this done go to <A
1300 HREF="http://sourceforge.net/project/admin/editpackages.php?group_id=11118"
1302 >http://sourceforge.net/project/admin/editpackages.php?group_id=11118</A
1304 making sure you are logged in. Find your target platform in the
1305 second column, and click <TT
1309 then need to create a new release for your package, using the format
1312 >$VERSION ($CODE_STATUS)</TT
1320 > Now just follow the prompts. Be sure to add any appropriate Release
1321 notes. You should see your freshly uploaded packages in
1324 >"Step 2. Add Files To This Release"</SPAN
1326 appropriate box(es). Remember at each step to hit the
1329 >"Refresh/Submit"</SPAN
1330 > buttons! You should now see your
1331 file(s) listed in Step 3. Fill out the forms with the appropriate
1332 information for your platform, being sure to hit <SPAN
1336 for each file. If anyone is monitoring your platform, check the
1340 > box at the very bottom to notify them of
1341 the new package. This should do it!
1344 > If you have made errors, or need to make changes, you can go through
1345 essentially the same steps, but select <TT
1361 >6.5. After the Release</A
1364 > When all (or: most of the) packages have been uploaded and made available,
1365 send an email to the <A
1366 HREF="mailto:ijbswa-announce@lists.sourceforge.net"
1370 >, Subject: "Version X.Y.Z available for download". Be sure to
1373 HREF="http://sourceforge.net/project/showfiles.php?group_id=11118"
1377 >, the release notes and the change log.
1412 HREF="webserver-update.html"
1421 >Testing Guidelines</TD
1431 >Update the Webserver</TD