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.
+The following programs are required to follow this process: ssh, gmake (GNU's version of make), autoconf, git, a web browser.
First you need to determine which version number the release will have.
X, the version major, is rarely ever changed. It is increased by one if turning a development branch into
stable substantially changes the functionality, user interface or configuration syntax. Majors 1 and 2 were
- Junkbuster, and 3 will be the first stable Junkbuster, and 3 is the first stable Privoxy release. Tag all files in Git with the version number with "git tag
+ Tag all files in Git with the version number with "git tag -s
v_X_Y_Z". Don't use vX_Y_Z, ver_X_Y_Z, v_X.Y.Z (won't work) etc. Also suggested: Developer Manual (doc/webserver/developer-manual) and
ChangeLog (top-level directory). FAQ and the manuals
- are HTML docs. There are also text versions in doc/text/ which could conceivably
- also be included. The documentation has been designed such that the manuals are linked to each other from parallel
directories, and should be packaged that way. privoxy-index.html can also be
included and can serve as a focal point for docs and other links of interest (and possibly renamed to
@@ -328,10 +326,11 @@ for-privoxy-version=3.0.11
should be left in tact as well. Other configuration files (default.action and default.filter) should be installed as the new defaults, but all previously installed
- configuration files should be preserved as backups. This is just good manners :-) These files are likely to
- change between releases and contain important new features and bug fixes. Other configuration files (default.action, regression-tests.action and default.filter) should be installed
+ as the new defaults, but all previously installed configuration files should be preserved as backups. This
+ is just good manners :-) These files are likely to change between releases and contain important new
+ features and bug fixes. Please check platform specific notes in this doc, if you haven't done
First, make sure that you have freshly exported the right version
- into an empty directory. (See "Building and releasing packages" above). Then run: To upload the package to Sourceforge, simply issue
- $ git tag
# to see the tags
- $ git log [last release tag]..HEAD > /tmp/log
+ $ git log [last release tag]..master > /tmp/log
# get the commit log since the last release
$ utils/makeChangeLog /tmp/log > /tmp/change.log
# reformat the commit log
@@ -198,12 +197,12 @@ for-privoxy-version=3.0.11
is version sensitive, so that the user will get appropriate help for his/her release. So with each release a
fresh version should be uploaded to the webserver (this is in addition to the main User
Manual link from the main page since we need to keep manuals for various versions available). The CGI
- pages will link to something like http://privoxy.org/$(VERSION)/user-manual/. This
- will need to be updated for each new release. There is no Makefile target for this at this time!!! It needs
- to be done manually.
+ pages will link to something like https://www.privoxy.org/$(VERSION)/user-manual/.
+ This needs to be updated for each new release and is done with the "webserver"
+ target.
6.3.2. Source Tarball
@@ -366,215 +365,244 @@ for-privoxy-version=3.0.11
-
cd current
- autoheader && autoconf && ./configure
+ autoheader && autoconf && ./configure
Note that the docbook generated files might need some hand editing, so the Windows build makefile does not + rebuild the docs.
+First, make sure that you have freshly exported the right version + into an empty directory. (See "Building and releasing packages" above).
+Then you can build the package. This is fully automated, and is controlled by windows/GNUmakefile. All you need to do is:
- make tarball-upload+ cd windows + make |
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.
-In following text, replace dist with either "rh" for Red Hat or "suse" for SuSE.
-First, make sure that you have freshly exported the right version - into an empty directory. (See "Building and releasing packages" above).
-As the only exception to not changing anything after export from Git, now examine the file privoxy-dist.spec and make sure - that the version information and the RPM release number are correct. The RPM release numbers for each version - start at one. Hence it must be reset to one if this is the first RPM for dist which is built from version X.Y.Z. Check the file list if unsure. Else, it - must be set to the highest already available RPM release number for that version plus one.
-Then run:
+Now you can manually rename privoxy_setup.exe to privoxy_setup_X.Y.Z.exe, and the build directory to privoxy_X.Y.Z. Create a .zip file of the newly renamed privoxy_X.Y.Z + directory, GPG sign the installer and zip file,
- cd current - autoheader && autoconf && ./configure+ $ gpg --armor --detach --sign privoxy_setup_X.Y.Z.exe + $ gpg --armor --detach --sign privoxy_X.Y.Z.zip |
Then do
+and upload the files to SourceForge.
+When releasing the package on SourceForge, use the release notes and Change Log from the source tarball + package.
+Using git-buildpackage we start with a clone of the last Debian version:
- make dist-dist+ gbp clone https://salsa.debian.org/debian/privoxy.git + cd privoxy |
To upload the package to Sourceforge, simply issue
+or if the repository is already there
- make dist-upload rpm_packagerev+ cd privoxy + gbp pull |
where rpm_packagerev is the RPM release number as determined above. Go - to the displayed URL and release the file publicly 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 get the OS/2 Setup - module:
+Now import the newly released upstream tarball via debian/watch file:
- cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co os2setup+ gbp import-orig --uscan |
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. Specifically, - 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,
+Next update all Debian quilt patches to the new version:
- installExeName='privoxyos2_setup_X.Y.Z.exe'+ while quilt push; do quilt refresh; done |
Next, edit the IJB.wis file so the release number matches in the PACKAGEID section:
+If some patch is no longer required (because it is already merged upstream), it can be removed using
- PACKAGEID="Privoxy Team\Privoxy\Privoxy Package\X\Y\Z"+ quilt delete XX_patchname.patch + git rm debian/patches/XX_patchname.patch |
You're now ready to build. Run:
+If the patch needs modification, you can apply, edit and update it with
- os2build+ quilt push -f + quilt edit some_file + quilt refresh |
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:
+until
- ssh cf.sourceforge.net+ while quilt push; do quilt refresh; done |
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:
+succeeds. Then you can
- cd current - autoheader && autoconf && ./configure+ quilt pop -a |
Then run
+Now add a new entry to the debian/changelog representing the new version:
- gmake solaris-dist+ dch -v 3.0.30-1 |
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.
-Note that the docbook generated files might need some hand editing, so the Windows build makefile does not - rebuild the docs.
-First, make sure that you have freshly exported the right version - into an empty directory. (See "Building and releasing packages" above).
-Then you can build the package. This is fully automated, and is controlled by windows/GNUmakefile. All you need to do is:
+and describe what you did before and don't forget to git commit all changes.
+Now you can build the package on the local machine using
- cd windows - make+ gbp buildpackage -us -uc |
Now you can manually rename privoxy_setup.exe to privoxy_setup_X.Y.Z.exe, and the build directory to privoxy_X.Y.Z. Create a .zip file of the newly renamed privoxy_X.Y.Z - directory, GPG sign the installer and zip file,
+You should check for warnings using
- $ gpg --armor --detach --sign privoxy_setup_X.Y.Z.exe - $ gpg --armor --detach --sign privoxy_X.Y.Z.zip+ lintian -iI ../build-area/privoxy_3.0.30-1_amd64.changes |
and upload the files 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 add a log entry to - debian/changelog, if it is not already there, for example by running:
+Maybe rebuild the package in different defined cowbuilder environments like
- debchange -v 3.0.29-UNRELEASED-1 "New upstream version"+ sudo cowbuilder --build --basepath /var/cache/pbuilder/base.cow ../build-area/privoxy_3.0.30-1.dsc |
Then, run:
+And try to run autopackage testing suite on the result:
- dpkg-buildpackage -rfakeroot -us -uc -b+ autopkgtest /var/cache/pbuilder/result/privoxy_3.0.30-1_amd64.changes -s -- schroot sid |
This will create ../privoxy_3.0.29-UNRELEASED-1_i386.deb which can be uploaded. To - upload the package to Sourceforge, simply issue
+Or just push the changes to salsa.debian.org, where a CI pipeline is defined for the package, that builds + and tests it.
+If everything is okay, run cowbuilder with i386 and amd64 environments for current Debian stable release and + build privoxy_3.0.30-1_i386.deb and privoxy_3.0.30-1_amd64.deb. Then sign both files:
- make debian-upload+ gpg --detach-sign --armor privoxy_3.0.30-1_i386.deb + gpg --detach-sign --armor privoxy_3.0.30-1_amd64.deb |
Create a README file containing the recent block from debian/changelog and upload the two packages, the two + signatures and the README to a freshly created folder below + https://sourceforge.net/projects/ijbswa/files/Debian/
+For building just a git snapshot build the following workflow may be useful. First create a build + environment, for this you may have to run the following commands:
+
+ sudo apt install build-essential devscripts + sudo apt-get build-dep privoxy+ |
+
After this enter the checked out privoxy git tree and check that all (new) build dependencies are met:
+
+ dpkg-checkbuilddeps+ |
+
If something is missing, just add it using
+
+ sudo apt install foobar+ |
+
Now you may update debian/changelog, especially the version number using
+
+ dch+ |
+
and finally build the package:
+
+ debuild -us -uc -b+ |
+
If everything went okay, you may find the resulting Debian package in the parent directory.
+You may want to clean up the build tree using
+
+ debian/rules clean+ |
+
And maybe repair some artefacts using one or both of the following commands:
+
+ git reset --hard + git clean -fd+ |
+
First, make sure that you have freshly exported the right version into an empty directory. (See "Building and releasing packages" above).
-There are three modules available in the Git repository for use on Mac OS X, though technically only two of - them generate a release (the other can be used to install from source).
+There are three modules available in the CVS repository backups for use on Mac OS X, though technically only + two of them generate a release (the other can be used to install from source).
The OSXPackageBuilder module generates OS X installer packages supporting all Macs running OS X 10.4 and - above. Obtain it from Git as follows into a folder parallel to the exported privoxy source:
+ above. Obtain it from CVS as follows into a folder parallel to the exported privoxy source:|
@@ -591,12 +619,12 @@ for-privoxy-version=3.0.11
makes it clear which package is for whichversion of OS X.
- 6.3.8.2. osxsetup module - (DEPRECATED)+6.3.5.2. osxsetup module + (DEPRECATED) (Documentation out of date)This module is deprecated since the installer it generates places all Privoxy files in one folder in a non-standard location, and supports only Intel Macs running OS X 10.6 or higher. -Check out the module from Git as follows into a folder parallel to the exported privoxy source: +Check out the module from CVS as follows into a folder parallel to the exported privoxy source:
|