When we release versions of Privoxy, our work leaves our cozy secret lab and has to work in the cold RealWorld[tm]. Once it is released, there is no way to call it back, so it is very important that great care is taken to ensure that everything runs fine, and not to introduce problems in the very last minute.
So when releasing a new version, please adhere exactly to the procedure outlined in this chapter.
The following programs are required to follow this process: ncftpput (ncftp), scp, ssh (ssh), gmake (GNU's version of make), autoconf, cvs.
In the following text, replace X, Y and Z with the actual version number (X = major, Y = minor, Z = point):
The following must be done by one of the developers prior to each new release.
Make sure that everybody who has worked on the code in the last couple of days has had a chance to yell "no!" in case they have pending changes/fixes in their pipelines.
Increment the version number and increase or reset the RPM release number in configure.in as appropriate.
If the default actionsfile has changed since last release, bump up its version info in this line:
{+add-header{X-Actions-File-Version: A.B} -filter -no-popups}
|
Then change the version info in doc/webserver/actions/index.php, line: '$required_actions_file_version = "A.B";'
If the HTML documentation is not in sync with the SGML sources you need to regenerate it. (If in doubt, just do it.) See the Section "Updating the webserver" in this manual for details.
Commit all files that were changed in the above steps!
Tag all files in CVS with the version number with "cvs tag v_X_Y_Z". Don't use vX_Y_Z, ver_X_Y_Z, v_X.Y.Z (won't work) etc.
Now the individual packages can be built and released. Note that for GPL reasons the first package to be released is always the source tarball.
For all types of packages, including the source tarball, you must make sure that you build from clean sources by exporting the right version from CVS into an empty directory:.
mkdir dist # delete or choose different name if it already exists
cd dist
cvs -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa login
cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa export -r v_X_Y_Z current
|
Do NOT change a single bit, including, but not limited to version information after export from CVS. This is to make sure that all release packages, and with them, all future bug reports, are based on exactly the same code.
Please find additional instructions for the source tarball and the individual platform dependent binary packages below.
First, make sure that you have freshly exported the right version into an empty directory. (See "Building and releasing packages" above). Then run:
cd current autoheader && autoconf && ./configure |
Then do:
make tarball-dist |
To upload the package to Sourceforge, simply issue
make tarball-upload |
Go to the displayed URL and release the file publicly on Sourceforge. For the change log field, use the relevant section of the ChangeLog file.
First, make sure that you have freshly exported the right version into an empty directory. (See "Building and releasing packages" above). Then run:
cd current autoheader && autoconf && ./configure |
Then do
make suse-dist (or make redhat-dist) |
To upload the package to Sourceforge, simply issue
make suse-upload (or make redhat-upload) |
Go to the displayed URL and release the file publicly on Sourceforge. Use the release notes and çhange log from the source tarball package.
First, make sure that you have freshly exported the right version into an empty directory. (See "Building and releasing packages" above). Then get the OS/2 Setup module:
cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co os2setup |
You will need a mix of development tools. The main compilation takes place with IBM Visual Age C++. Some ancillary work takes place with GNU tools, available from various sources like hobbes.nmsu.edu. Specificially, you will need autoheader, autoconf and sh tools. The packaging takes place with WarpIN, available from various sources, including its home page: xworkplace.
Change directory to the os2setup directory. Edit the os2build.cmd file to set the final executable filename. For example,
installExeName='privoxyos2_setup_X.Y.Z.exe' |
Next, edit the IJB.wis file so the release number matches in the PACKAGEID section:
PACKAGEID="Privoxy Team\Privoxy\Privoxy Package\X\Y\Z" |
You're now ready to build. Run:
os2build |
You will find the WarpIN-installable executable in the ./files directory. Upload this anonymously to uploads.sourceforge.net/incoming, create a release for it, and you're done. Use the release notes and Change Log from the source tarball package.
Login to Sourceforge's compilefarm via ssh:
ssh cf.sourceforge.net |
Choose the right operating system (not the Debian one). When logged in, make sure that you have freshly exported the right version into an empty directory. (See "Building and releasing packages" above). Then run:
cd current autoheader && autoconf && ./configure |
Then run
gmake solaris-dist |
which creates a gzip'ed tar archive. Sadly, you cannot use make solaris-upload on the Sourceforge machine (no ncftpput). You now have to manually upload the archive to Sourceforge's ftp server and release the file publicly. Use the release notes and Change Log from the source tarball package.
You should ensure you have the latest version of Cygwin (from http://www.cygwin.com/). Run the following commands from within a Cygwin bash shell.
First, make sure that you have freshly exported the right version into an empty directory. (See "Building and releasing packages" above). Then get the Windows setup module:
cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co winsetup
|
Then you can build the package. This is fully automated, and is controlled by winsetup/GNUmakefile. All you need to do is:
cd winsetup
make
|
Now you can manually rename privoxy_setup.exe to privoxy_setup_X_Y_Z.exe, and upload it to SourceForge. When releasing the package on SourceForge, use the release notes and Change Log from the source tarball package.
First, make sure that you have freshly exported the right version into an empty directory. (See "Building and releasing packages" above). Then, run:
cd current autoheader && autoconf && ./configure |
Then do FIXME.
First, make sure that you have freshly exported the right version into an empty directory. (See "Building and releasing packages" above). Then get the Mac OSX setup module:
cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co osxsetup |
Then run:
cd osxsetup build |
This will run autoheader, autoconf and configure as well as make. Finally, it will copy over the necessary files to the ./osxsetup/files directory for further processing by PackageMaker.
Bring up PackageMaker with the PrivoxyPackage.pmsp definition file, modify the package name to match the release, and hit the "Create package" button. If you specify ./Privoxy.pkg as the output package name, you can then create the distributable zip file with the command:
zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg |
You can then upload privoxyosx_setup_x.y.z.zip anonymously to uploads.sourceforge.net/incoming, create a release for it, and you're done. Use the release notes and Change Log from the source tarball package.
Login to Sourceforge's compilefarm via ssh:
ssh cf.sourceforge.net |
Choose the right operating system. When logged in, make sure that you have freshly exported the right version into an empty directory. (See "Building and releasing packages" above). Then run:
cd current autoheader && autoconf && ./configure |
Then run:
gmake freebsd-dist |
which creates a gzip'ed tar archive. Sadly, you cannot use make freebsd-upload on the Sourceforge machine (no ncftpput). You now have to manually upload the archive to Sourceforge's ftp server and release the file publicly. Use the release notes and Change Log from the source tarball package.
First, make sure that you have freshly exported the right version into an empty directory. (See "Building and releasing packages" above). Then run:
cd current autoheader && autoconf && ./configure |
Then do FIXME.
First, make sure that you have freshly exported the right version into an empty directory. (See "Building and releasing packages" above). Then run:
cd current autoheader && autoconf && ./configure |
Then do FIXME.
Login to Sourceforge's compilefarm via ssh:
ssh cf.sourceforge.net |
Choose the right operating system. When logged in, make sure that you have freshly exported the right version into an empty directory. (See "Building and releasing packages" above). Then run:
cd current autoheader && autoconf && ./configure |
Then run:
make aix-dist |
which creates a gzip'ed tar archive. Sadly, you cannot use make aix-upload on the Sourceforge machine (no ncftpput). You now have to manually upload the archive to Sourceforge's ftp server and release the file publicly. Use the release notes and Change Log from the source tarball package.
When all (or: most of the) packages have been uploaded and made available, send an email to the announce mailing list, Subject: "Version X.Y.Z available for download". Be sure to include the download location, the release notes and the change log.