X-Git-Url: http://www.privoxy.org/gitweb/?a=blobdiff_plain;f=doc%2Fsource%2Fdeveloper-manual.sgml;h=5049edd95b7066b1f506ab2a67097fe93b359246;hb=ec3786121a8db0be59e217dd794d61be9d9dc134;hp=a35db57d014275b07413fa8fea5d5ba8827340fd;hpb=82ca06f718357047cf1b171ac663d080cb2b1271;p=privoxy.git
diff --git a/doc/source/developer-manual.sgml b/doc/source/developer-manual.sgml
index a35db57d..5049edd9 100644
--- a/doc/source/developer-manual.sgml
+++ b/doc/source/developer-manual.sgml
@@ -1,5 +1,5 @@
+
@@ -7,12 +7,14 @@
-
+
+
+
]>
+
+ Copyright &my-copy; 2001, 2002 by
+ Privoxy Developers
+
+
+
+
+ $Id: developer-manual.sgml,v 1.45 2002/05/19 23:01:54 hal9 Exp $
+
+
+
@@ -65,24 +81,25 @@
]]>
- The developer manual gives the users information on how to help the developer
- team. It provides guidance on coding, testing, documentation and other
- issues.
-
+ The developer manual provides guidance on coding, testing, packaging, documentation
+ and other issues of importance to those involved with
+ Privoxy development. It is mandatory (and helpful!) reading
+ for anyone who wants to join the team.
+
- &p-intro;
+
You can find the latest version of the this manual at http://www.privoxy.org/developer-manual/.
- Please see the Contact section
+ Please see the Contact section
on how to contact the developers.
-
@@ -90,18 +107,9 @@
-
-
-
-
-
-
-
-
-
- Introduction
+ Introduction
- Quickstart to Privoxy Development
+ Quickstart to Privoxy Development
You'll need an account on Sourceforge to support our
- development. Mail your ID to the list and wait until a project
- manager has added you.
+ url="http://sourceforge.net/">Sourceforge to support our
+ development. Mail your ID to the list and wait until a
+ project manager has added you.
For the time being (read, this section is under construction), please
- note the following guidelines for changing stuff in the code. If it is
-
-
- A bugfix / clean-up / cosmetic thing: shoot
-
-
- A new feature that can be turned off: shoot
-
-
- A clear improvement w/o side effects on other parts of the code: shoot
-
-
- A matter of taste: ask the list
-
-
- A major redesign of some part of the code: ask the list
-
-
+ refer to the extensive comments in the source code.
+
+
+
+
+ The CVS Repository
- Note that near a major public release, we get a bit more cautious - if
- unsure, it doesn't hurt to ask first.
+ If you intend to help us with programming, documentation or packaging
+ you will need write access to our holy grail, the CVS repository.
+ Please read this chapter completely before accessing via CVS.
+
+ Access to CVS
+
+ The project's CVS repository is hosted on
+ SourceForge.
+ Please refer to the chapters 6 and 7 in
+ SF's site
+ documentation for the technical access details for your
+ operating system. For historical reasons, the CVS server is
+ called cvs.ijbswa.sourceforge.net, the repository is
+ called ijbswa, and the source tree module is called
+ current.
+
+
+
+ CVS Commit Guideline
+
+ The source tree is the heart of every software project. Every effort must
+ be made to ensure that it is readable, compilable and consistent at all
+ times. We therefore ask anyone with CVS access to strictly adhere to the
+ following guidelines:
+
+
+ Never (read: never, ever) be tempted to commit
+ that small change without testing it thoroughly first. When we're
+ close to a public release, ask a fellow developer to review your
+ changes.
+
+
+ Your commit message should give a concise overview of what you
+ changed (no big details) and why you changed it
+ Just check previous messages for good examples.
+
+
+ Don't use the same message on multiple files, unless it equally applies to
+ all those files.
+
+
+ If your changes span multiple files, and the code won't recompile unless
+ all changes are commited (e.g. when changing the signature of a function),
+ then commit all files one after another, without long delays in beween.
+ If necessary, prepare the commit messages in advance.
+
+
+ Before changing things on CVS, make sure that your changes are in line
+ with the team's general consensus on what should be done (see below).
+
+
+
+
+
+ Discussing Changes First
+
+ We don't have a too formal policy on this, just use common sense. Hints: If it is..
+
+
+ ..a bugfix / clean-up / cosmetic thing: shoot
+
+
+ ..a new feature that can be turned off: shoot
+
+
+ ..a clear improvement w/o side effects on other parts of the code: shoot
+
+
+ ..a matter of taste: ask the list
+
+
+ ..a major redesign of some part of the code: ask
+ the list
+
+
+
+
+ Note that near a major public release, we get a bit more cautious - if
+ unsure, it doesn't hurt to ask first. There is always the possibility
+ to submit a patch to the patches
+ tracker instead.
+
+
@@ -230,7 +308,6 @@
updated (this is done just prior to a new release).
-
Quickstart to Docbook and SGML
@@ -275,51 +352,57 @@
Some common elements that you likely will use:
-
-
- <para></para>, paragraph delimiter. Most
- text needs to be within paragraph elements (there are some exceptions).
-
-
- <emphasis></emphasis>, the stylesheets make this
- italics.
-
-
- <filename></filename>, files and directories.
-
-
- <command></command>, command examples.
-
-
- <literallayout></literallayout>, like
- <pre>, more or less.
-
-
- <itemizedlist></itemizedlist>, list with bullets.
-
-
- <listitem></listitem>, member of the above.
-
-
- <screen></screen>, screen output, implies
- <literallayout>.
-
-
- <ulink url="example.com"></ulink>, like
- HTML <a> tag.
-
-
- <quote></quote>, for, doh, quoting text.
-
-
+
+
+
+ <para></para>, paragraph delimiter. Most
+ text needs to be within paragraph elements (there are some exceptions).
+
+
+ <emphasis></emphasis>, the stylesheets
+ make this italics.
+
+
+ <filename></filename>, files and directories.
+
+
+ <command></command>, command examples.
+
+
+ <literallayout></literallayout>, like
+ <pre>, more or less.
+
+
+ <itemizedlist></itemizedlist>, list with bullets.
+
+
+ <listitem></listitem>, member of the above.
+
+
+ <screen></screen>, screen output, implies
+ <literallayout>.
+
+
+ <ulink url="example.com"></ulink>, like
+ HTML <a> tag.
+
+
+ <quote></quote>, for, doh, quoting text.
+
+
+
Look at any of the existing docs for examples of all these and more.
+
+ You might also find Writing Documentation
+ Using DocBook - A Crash Course
useful.
+
-
<application>Privoxy</application> Documentation Style
@@ -1644,7 +1727,7 @@ static void unload_re_filterfile( void *f ) { ... }
Example for file comments:
-const char FILENAME_rcs[] = "$Id: developer-manual.sgml,v 1.32 2002/04/11 21:29:58 jongfoster Exp $";
+const char FILENAME_rcs[] = "$Id: developer-manual.sgml,v 1.45 2002/05/19 23:01:54 hal9 Exp $";
/*********************************************************************
*
* File : $Source$
@@ -1704,7 +1787,7 @@ const char FILENAME_h_rcs[] = FILENAME_H_VERSION;
#ifndef _FILENAME_H
#define _FILENAME_H
-#define FILENAME_H_VERSION "$Id: developer-manual.sgml,v 1.32 2002/04/11 21:29:58 jongfoster Exp $"
+#define FILENAME_H_VERSION "$Id: developer-manual.sgml,v 1.45 2002/05/19 23:01:54 hal9 Exp $"
/*********************************************************************
*
* File : $Source$
@@ -1800,13 +1883,6 @@ int FUNCTION_NAME( void *param1, const char *x )
-
- Version Control Guidelines
- To be filled. note on cvs comments. Don't only comment what you did,
- but also why you did it!
-
-
-
Testing Guidelines
To be filled.
@@ -1863,24 +1939,79 @@ at sourceforge. Three simple steps:
- Releasing a new version
+ Releasing a New Version
+
+ 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.
+
- To minimize trouble with distribution contents, web-page
- errors and the like, we strongly encourage you
- to follow this section if you prepare a new release of
- code or new pages on the webserver.
+ 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),
-gmake (GNU's version of make), autoconf, cvs, ???.
+ ncftpput (ncftp), scp, ssh (ssh),
+ gmake (GNU's version of make), autoconf, cvs.
+
+
+ Version numbers
+
- Replace X, Y and Z with the actual version number (X = major, Y = minor, Z = point):
+ First you need to determine which version number the release will have.
+ Privoxy version numbers consist of three numbers,
+ separated by dots, like in X.Y.Z, where:
+
+
+
+ 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
+ Privoxy release.
+
+
+
+
+ Y, the version minor, represents the branch within the major version.
+ At any point in time, there are two branches being maintained:
+ The stable branch, with an even minor, say, 2N, in which no functionality is
+ being added and only bugfixes are made, and 2N+1, the development branch, in
+ which the further development of Privoxy takes
+ place.
+ This enables us to turn the code upside down and inside out, while at the same time
+ providing and maintaining a stable version.
+ The minor is reset to zero (and one) when the major is inrcemented. When a development
+ branch has matured to the point where it can be turned into stable, the old stable branch
+ 2N is given up (i.e. no longer maintained), the former development branch 2N+1 becomes the
+ new stable branch 2N+2, and a new development branch 2N+3 is opened.
+
+
+
+
+ Z, the point or sub version, represents a release of the software within a branch.
+ It is therefore incremented immediately before each code freeze.
+ In development branches, only the even point versions correspond to actual releases,
+ while the odd ones denote the evolving state of the sources on CVS in between.
+ It follows that Z is odd on CVS in development branches most of the time. There, it gets
+ increased to an even number immediately before a code freeze, and is increased to an odd
+ number again immediately thereafter.
+ This ensures that builds from CVS snapshots are easily distinguished from released versions.
+ The point version is reset to zero when the minor changes.
+
+
+
+
+
- Before the Release
+ Before the Release: Freeze
The following must be done by one of the
developers prior to each new release.
@@ -1891,41 +2022,45 @@ at sourceforge. Three simple steps:
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.
+ they have pending changes/fixes in their pipelines. Announce the
+ freeze so that nobody will interfere with last minute changes.
- Increment the version number in configure.in in
- CVS. Also, increase or reset the RPM release number in
- configure.in as appropriate. Do NOT
- touch version information after export from CVS.
- All packages will use the version and release data
- from configure.in.
- Local files should not be changed, except prior to a CVS commit!!!
- This way we are all on the same page!
+ Increment the version number (point from odd to even in development
+ branches!) in configure.in.
- If the default actionsfile has changed since last
- release, bump up its version info in this line:
+ If default.action has changed since last
+ release (i.e. software release or standalone actions file release),
+ bump up its version info to A.B 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 and upload it to the webserver. (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
@@ -1933,111 +2068,262 @@ at sourceforge. Three simple steps:
Don't use vX_Y_Z, ver_X_Y_Z, v_X.Y.Z (won't work) etc.
-
+
- The first package uploaded should be the official
- tarball
release, as required by the GPL. This is built
- with the make tarball-dist
Makefile
- target, and then can be uploaded with
- make tarball-upload
(see below).
+ If the release was in a development branch, increase the point version
+ from even to odd (X.Y.(Z+1)) again in configure.in and
+ commit your change.
+
+
+
+
+ On the webserver, copy the user manual to a new top-level directory
+ called X.Y.Z. This ensures that help links from the CGI
+ pages, which have the version as a prefix, will go into the right version of the manual.
+ If this is a development branch release, also symlink X.Y.(Z-1)
+ to X.Y.Z and X.Y.(Z+1) to
+ . (i.e. dot).
- Update the webserver
-
- All files must be group-readable and group-writable (or no one else
- will be able to change them)! To update the webserver, create any
- pages locally in the doc/webserver/* directory (or
- create new directories under doc/webserver), then do
-
-
-
- make webserver
-
-
-
- This will do the upload to the webserver (www.privoxy.org).
+
+ Building and Releasing the Packages
+
+ 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.
+
- Note that make dok
- (or make redhat-dok
) creates
- doc/webserver/user-manual,
- doc/webserver/developer-manual,
- doc/webserver/faq and
- doc/webserver/index.html automatically.
- (doc/webserver/man-page/privoxy-man-page.html
- is created by a separate Makefile target, make
- man
, due to dependencies on some obscure perl scripts.
- See comments in GNUmakefile.)
-
-
- Someone should also commit these to CVS so that packagers without the
- ability to build docs locally, have access to them. This is a separate
- step, and should also be done before each official release.
+ 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. And details
+ on the Sourceforge release process below that.
+
+
+ Note on Privoxy Packaging
+
+ Please keep these general guidelines in mind when putting together
+ your package. These apply to all platforms!
+
- Please do NOT use any other means of transferring files to the
- webserver. make webserver
not only
- uploads, but will make sure that the appropriate permissions are
- preserved for shared group access.
+
+
+
+ Privoxy requires
+ write access to: all *.action files, all
+ logfiles, and the trust file. You will
+ need to determine the best way to do this for your platform.
+
+
+
+
+ Please include up to date documentation. At a bare minimum:
+
+
+
+ LICENSE (toplevel directory)
+
+
+
+
+ README (toplevel directory)
+
+
+
+
+ AUTHORS (toplevel directory)
+
+
+
+
+ man page (toplevel directory, Unix-like
+ platforms only)
+
+
+
+
+ The User Manual (doc/webserver/user-manual/)
+
+
+
+
+ FAQ (doc/webserver/faq/)
+
+
+
+ Also suggested: Developer Manual
+ (doc/webserver/devel-manual) and ChangeLog
+ (toplevel 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. index.html can also be included and
+ can serve as a focal point for docs and other links of interest.
+ This should be one level up from the manuals. There are two
+ css stylesheets that can be included for better presentation:
+ p_doc.css and p_web.css.
+ These should be in the same directory with
+ index.html, (i.e. one level up from the manual
+ directories).
+
+
+
+
+ user.action is designed for local preferences.
+ Make sure this does not get overwritten!
+
+
+
+
+ Other configuration files should be installed as the new defaults,
+ but all previously installed configuration files should be preserved
+ as backups. This is just good manners :-)
+
+
+
+
+ Please check platform specific notes in this doc, if you haven't
+ done Privoxy
packaging before for other platform
+ specific issues. Conversely, please add any notes that you know
+ are important for your platform (or contact one of the doc
+ maintainers to do this if you can't).
-
+
- SuSE or Red Hat
-
- Ensure that you have the latest code version. Hence run:
+
+
+
+
+
+ Source Tarball
+
+ First, make sure that you have freshly exported the right
+ version into an empty directory. (See "Building and releasing
+ packages" above). Then run:
- 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
cd current
-
+ autoheader && autoconf && ./configure
+
- first.
+ 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.
+
+
+
+ SuSE, Conectiva or Red Hat RPM
+
+ 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 CVS,
+ 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:
+ cd current
autoheader && autoconf && ./configure
-
+
Then do
- make suse-dist or make redhat-dist
-
+ make dist-dist
+
To upload the package to Sourceforge, simply issue
- make suse-upload (or make redhat-upload)
-
+ make dist-upload rpm_packagerev
+
+ 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.
-
+
- OS/2
+ OS/2
- Ensure that you have the latest code version. Hence run:
+ 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 -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
- cd ..
cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co os2setup
-
+
You will need a mix of development tools.
@@ -2053,55 +2339,58 @@ at sourceforge. Three simple steps:
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
-
- And in the ./files directory you will have the
- WarpIN-installable executable.
- Upload this anonymously to
- uploads.sourceforge.net/incoming, create a release
- for it, and you're done.
+
-
+
+ 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.
+
+
- Solaris
+ Solaris
- Login to Sourceforge's compilefarm via ssh
+ Login to Sourceforge's compilefarm via ssh:
ssh cf.sourceforge.net
-
+
- Choose the right operating system (not the Debian one). If you have
- downloaded Privoxy before,
+ 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:
- 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
cd current
-
-
-
- If not, please checkout
- Privoxy via CVS first. Run:
-
-
-
autoheader && autoconf && ./configure
-
+
Then run
@@ -2109,37 +2398,32 @@ at sourceforge. Three simple steps:
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.
+ the file publicly. Use the release notes and Change Log from the
+ source tarball package.
-
+
- Windows
+ Windows
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 check out a clean copy of the correct code version, by running:
+ 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:
- mkdir dist
- 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 .
-
-
-
- (Note: It is important that this is a clean copy of the code,
- do not re-use a working directory after you have manually compiled
- there).
+ 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
@@ -2150,56 +2434,52 @@ at sourceforge. Three simple steps:
cd winsetup
make
-
+
Now you can manually rename privoxy_setup.exe to
privoxy_setup_X_Y_Z.exe, and upload it to
- SourceForge.
+ SourceForge. When releasing the package on SourceForge, use the release notes
+ and Change Log from the source tarball package.
-
+
- Debian
+ Debian
- Ensure that you have the latest code version. Hence run:
+ First, make sure that you have freshly exported the right
+ version into an empty directory. (See "Building and releasing
+ packages" above). Then, run:
- 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
cd current
-
-
-
- first. Run:
-
-
-
autoheader && autoconf && ./configure
-
+
Then do FIXME.
-
+
- Mac OSX
+ Mac OSX
- Ensure that you have the latest code version. Hence run:
+ 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 -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
- cd ..
cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co osxsetup
-
+
+
+
+ Then run:
- From the osxsetup directory, run:
+ cd osxsetup
build
-
+
This will run autoheader, autoconf and
@@ -2212,49 +2492,40 @@ at sourceforge. Three simple steps:
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.
+ create a release for it, and you're done. Use the release notes
+ and Change Log from the source tarball package.
-
+
- FreeBSD
-
- Change the version number of Privoxy in the
- configure.in file. Run:
-
- autoheader && autoconf && ./configure
-
- Then ...
-
+ FreeBSD
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:
- 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
cd current
-
-
-
- Run:
-
-
-
autoheader && autoconf && ./configure
-
+
Then run:
@@ -2262,133 +2533,71 @@ zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg
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.
+ the file publicly. Use the release notes and Change Log from the
+ source tarball package.
-
+
- Tarball
+ HP-UX 11
- Ensure that you have the right code version. Hence run:
+ First, make sure that you have freshly exported the right
+ version into an empty directory. (See "Building and releasing
+ packages" above). Then run:
- 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
cd current
-
-
-
- first. Run:
-
-
-
autoheader && autoconf && ./configure
-
-
-
- Then do:
-
-
-
- make tarball-dist
-
-
-
- To upload the package to Sourceforge, simply issue
-
-
-
- make tarball-upload
-
-
-
- Goto the displayed URL and release the file publicly on Sourceforge.
-
-
-
- HP-UX 11
-
- Ensure that you have the latest code version. Hence run:
-
-
-
- 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
- cd current
-
-
-
- first. Run:
-
-
-
- autoheader && autoconf && ./configure
-
+
Then do FIXME.
-
+
- Amiga OS
+ Amiga OS
- Ensure that you have the latest code version. Hence run:
+ First, make sure that you have freshly exported the right
+ version into an empty directory. (See "Building and releasing
+ packages" above). Then run:
- 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
cd current
-
-
-
- first. Run:
-
-
-
autoheader && autoconf && ./configure
-
+
Then do FIXME.
-
+
- AIX
+ AIX
Login to Sourceforge's compilefarm via ssh:
ssh cf.sourceforge.net
-
+
- Choose the right operating system. If you have downloaded Privoxy
- before:
+ 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:
- 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
cd current
-
-
-
- If not, please checkout
- Privoxy via CVS first. Run:
-
-
-
autoheader && autoconf && ./configure
-
+
Then run:
@@ -2396,18 +2605,141 @@ zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg
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.
+ the file publicly. Use the release notes and Change Log from the
+ source tarball package.
-
+
+
+
+
+ Uploading and Releasing Your Package
+
+ After the package is ready, it is time to upload it
+ to SourceForge, and go through the release steps. The upload
+ is done via FTP:
+
+
+
+
+
+ Upload to: ftp://upload.sourceforge.net/incoming
+
+
+
+
+ user: anonymous
+
+
+
+
+ password: ijbswa-developers@lists.sourceforge.net
+
+
+
+
+
+ Or use the make targets as described above.
+
+
+ Once this done go to http://sourceforge.net/project/admin/editpackages.php?group_id=11118,
+ making sure you are logged in. Find your target platform in the
+ second column, and click Add Release. You will
+ then need to create a new release for your package, using the format
+ of $VERSION ($CODE_STATUS), e.g. &p-version;
+ (beta).
+
+
+ Now just follow the prompts. Be sure to add any appropriate Release
+ notes. You should see your freshly uploaded packages in
+ Step 2. Add Files To This Release
. Check the
+ appropriate box(es). Remember at each step to hit the
+ Refresh/Submit
buttons! You should now see your
+ file(s) listed in Step 3. Fill out the forms with the appropriate
+ information for your platform, being sure to hit Update
+ for each file. If anyone is monitoring your platform, check the
+ email
box at the very bottom to notify them of
+ the new package. This should do it!
+
+
+ If you have made errors, or need to make changes, you can go through
+ essentially the same steps, but select Edit Release,
+ instead of Add Release.
+
+
+
+
+ After the Release
+
+ 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.
+
+
+
+ Update the Webserver
+
+ When updating the webserver, please follow these steps to make
+ sure that no broken links, incosistent contents or permission
+ problems will occur:
+
+
+ If you have changed anything in the documentation source SGML files,
+ do:
+
+
+
+ make dok # (or make redkat-dok if make dok doesn't work for you)
+
+
+
+ That will generate doc/webserver/user-manual,
+ doc/webserver/developer-manual,
+ doc/webserver/faq and
+ doc/webserver/index.html automatically.
+
+
+ If you changed the manual page source, generate
+ doc/webserver/man-page/privoxy-man-page.html
+ by running make man
. (This is
+ a separate target due to dependencies on some obscure perl scripts.
+ See comments in GNUmakefile.)
+
+
+ If you want to add new files to the webserver, create them locally in
+ the doc/webserver/* directory (or
+ create new directories under doc/webserver).
+
+
+ Next, commit any changes from the above steps to CVS. All set? Then do
+
+
+
+ make webserver
+
+
+
+ This will do the upload to the
+ webserver (www.privoxy.org) and ensure all files and directories
+ there are group writable.
+
+
+ Please do NOT use any other means of transferring
+ files to the webserver to avoid permission problems.
+
+
+
Contacting the developers, Bug Reporting and Feature Requests
@@ -2415,22 +2747,30 @@ zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg
-
- Copyright and History
-Copyright
+
+Privoxy Copyright, License and History
+
©right;
+
+
+License
+
+ &license;
+
+
+
History
&history;
-
+
See also
@@ -2461,6 +2801,55 @@ zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg
Temple Place - Suite 330, Boston, MA 02111-1307, USA.
$Log: developer-manual.sgml,v $
+ Revision 1.45 2002/05/19 23:01:54 hal9
+ Add small section on general packaging guidelines (e.g. actions files must
+ be writable).
+
+ Revision 1.44 2002/05/15 03:55:17 hal9
+ Fix ulink -> link, and minor modification to release process section for
+ clarification.
+
+ Revision 1.43 2002/05/10 01:48:19 hal9
+ This is mostly proposed copyright/licensing additions and changes. Docs
+ are still GPL, but licensing and copyright are more visible. Also, copyright
+ changed in doc header comments (eliminate references to JB except FAQ).
+
+ Revision 1.42 2002/05/05 20:26:02 hal9
+ Sorting out license vs copyright in these docs.
+
+ Revision 1.41 2002/05/04 08:44:44 swa
+ bumped version
+
+ Revision 1.40 2002/05/04 00:43:43 hal9
+ -Remove TOC/first page kludge with proper stylesheet fix.
+ -Combined the two very brief sections: Intro and Quickstart.
+
+ Revision 1.39 2002/05/02 15:08:25 oes
+ Added explanation about version numbers and RPM package revisions
+
+ Revision 1.38 2002/04/29 02:20:31 hal9
+ Add info on steps for uploading and the release process on SF.
+
+ Revision 1.37 2002/04/26 17:23:29 swa
+ bookmarks cleaned, changed structure of user manual, screen and programlisting cleanups, and numerous other changes that I forgot
+
+ Revision 1.36 2002/04/26 05:25:23 hal9
+ Mass commit to catch a few scattered fixes.
+
+ Revision 1.35 2002/04/17 15:16:15 oes
+ Added link to docbook crash course
+
+ Revision 1.34 2002/04/15 23:39:32 oes
+ - Extended & fixed the release section
+ - Added CVS guideline sections
+ - Separated webserver section from release section
+ - Commented out boilerplate inclusion (If you don't know yet what it is,
+ you shouldn't mess with its code ;-)
+ - Nits & fixes
+
+ Revision 1.33 2002/04/12 03:49:53 hal9
+ Spell checked. Clarification on where docs are kept.
+
Revision 1.32 2002/04/11 21:29:58 jongfoster
Documenting Win32 release procedure