<!entity contacting SYSTEM "contacting.sgml">
<!entity copyright SYSTEM "copyright.sgml">
<!entity license SYSTEM "license.sgml">
-<!entity p-version SYSTEM "doc_version.tmp">
-<!entity p-status SYSTEM "doc_status.tmp">
-<!entity % p-not-stable "IGNORE">
+<!entity p-version "3.0.4">
+<!entity p-status "BETA">
+<!entity % p-not-stable "INCLUDE">
<!entity % p-stable "IGNORE">
<!entity % p-text "IGNORE"> <!-- define we are not a text only doc -->
<!entity % p-doc "INCLUDE"> <!-- and we are a formal doc -->
This file belongs into
ijbswa.sourceforge.net:/home/groups/i/ij/ijbswa/htdocs/
- $Id: developer-manual.sgml,v 2.2 2002/09/04 01:55:44 hal9 Exp $
+ $Id: developer-manual.sgml,v 2.7 2006/07/18 14:48:50 david__schmidt Exp $
Copyright (C) 2001, 2002 Privoxy Developers <developers@privoxy.org>
See LICENSE.
========================================================================
NOTE: Please read developer-manual/documentation.html before touching
- anything in this, or other Privoxy documentation.
+ anything in this, or other Privoxy documentation. You have been warned!
+ Failure to abide by this rule will result in the revocation of your license
+ to live a peaceful existence!
========================================================================
-->
</pubdate>
- <pubdate>$Id: developer-manual.sgml,v 2.2 2002/09/04 01:55:44 hal9 Exp $</pubdate>
+ <pubdate>$Id: developer-manual.sgml,v 2.7 2006/07/18 14:48:50 david__schmidt Exp $</pubdate>
<!--
<!-- ~~~~~ New section ~~~~~ -->
<sect2 id="quickstart"><title>Quickstart to Privoxy Development</title>
+ <!--
<para>
You'll need an account on <ulink
url="http://sourceforge.net/">Sourceforge</ulink> to support our
url="mailto:developers@privoxy.org">the list</ulink> and wait until a
project manager has added you.
</para>
+ -->
+ <para>
+ The first step is to join the <ulink
+ url="mailto:ijbswa-developers@lists.sourceforge.net">developer's mailing list</ulink>.
+ You can submit your ideas, or even better patches. Patches are best
+ submitted to the Sourceforge tracker set up for this purpose, but
+ can be sent to the list for review too.
+ </para>
<para>
You will also need to have a cvs package installed, which will
entail having ssh installed as well (which seems to be a requirement of
tools is also going to be important (particularly, autoconf and gmake).
</para>
<para>
- For the time being (read, this section is under construction), please
- refer to the extensive comments in the source code.
+ For the time being (read, this section is under construction), you can
+ also refer to the extensive comments in the source code. In fact,
+ reading the code is recommended in any case.
</para>
</sect2>
</sect1>
<!-- ~~~~~ New section ~~~~~ -->
<sect1 id="cvs"><title>The CVS Repository</title>
<para>
- 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.
+ If you become part of the active development team, you will eventually
+ need write access to our holy grail, the CVS repository. One of the
+ team members will need to set this up for you. Please read
+ this chapter completely before accessing via CVS.
</para>
<sect2 id="cvsaccess"><title>Access to CVS</title>
<ulink url="http://sourceforge.net/docman/?group_id=1">SF's site
documentation</ulink> for the technical access details for your
operating system. For historical reasons, the CVS server is
- called <literal>cvs.ijbswa.sourceforge.net</literal>, the repository is
+ called <literal>ijbswa.cvs.sourceforge.net</literal>, the repository is
called <literal>ijbswa</literal>, and the source tree module is called
<literal>current</literal>.
</para>
mentioned, the sources are in the <literal>current</literal>
<quote>module</quote>. Other modules are present for platform specific
issues. There is a webview of the CVS hierarchy at <ulink
- url="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ijbswa/">http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ijbswa/</ulink>,
+ url="http://ijbswa.cvs.sourceforge.net/ijbswa/">http://ijbswa.cvs.sourceforge.net/ijbswa/</ulink>,
which might help with visualizing how these pieces fit together.
</para>
<para>
is always at least one <quote>branch</quote> from the main trunk
devoted to a stable release series. The main trunk is where active
development takes place for the next stable series (e.g. 3.2.x).
- And for testing bugfixes for the stable series. Just prior to each
- stable series (e.g. 3.0.x), a branch is created just for stable series
- releases (e.g. 3.0.0 -> 3.0.1 -> 3.0.2, etc). Once the initial stable
- release of any stable branch has taken place, this branch is
- <emphasis>only used for bugfixes</emphasis>, which have had prior
- testing before being committed to CVS. (See <link
+ So just prior to each stable series (e.g. 3.0.x), a branch is created
+ just for stable series releases (e.g. 3.0.0 -> 3.0.1 -> 3.0.2, etc).
+ Once the initial stable release of any stable branch has taken place,
+ this branch is <emphasis>only used for bugfixes</emphasis>, which have
+ had prior testing before being committed to CVS. (See <link
linkend="versionnumbers">Version Numbers</link> below for details on
versioning.)
</para>
+ <para>
+ At one time there were two distinct branches: stable and unstable. The
+ more drastic changes were to be in the unstable branch. These branches
+ have now been merged to minimize time and effort of maintaining two
+ branches.
+ </para>
+ <!--
+ <para>
+ This will result in at least two active branches, which means there may
+ be occasions that require the same (or similar) item to be
+ checked into to two different places (assuming its a bugfix and needs
+ fixing in both the stable and unstable trees). This also means that in
+ order to have access to both trees, both will have to be checked out
+ separately. Use the <literal>cvs -r</literal> flag to check out a
+ branch, e.g: <literal>cvs co -r v_3_0_branch current</literal>.
+ </para>
+ -->
</sect2>
<sect2 id="cvscommit"><title>CVS Commit Guidelines</title>
<para>
<itemizedlist>
<listitem><para>
- Never (read: <emphasis>never, ever</emphasis>) be tempted to commit
- that small change without testing it thoroughly first. When we're
+ Please don't commit even
+ a small change without testing it thoroughly first. When we're
close to a public release, ask a fellow developer to review your
changes.
</para></listitem>
</itemizedlist>
</para>
+<!--
<para>
- Stable branches are handled with decidedly more care, especially after
- the initial *.*.0 release, and we are just in bugfix mode. In addition
- to the above, the below applies only to the stable branch (currently
- the v_3_0_branchpoint branch):
+ Stable branches are handled with more care, especially after the
+ initial *.*.0 release, and we are just in bugfix mode. In addition to
+ the above, the below applies only to the stable branch (currently the
+ <literal>v_3_0_branch</literal> branch):
</para>
<para>
<itemizedlist>
- <listitem><para>
- Do <emphasis>not commit anything</emphasis> into the stable branch,
- unless immediately before a new release! There needs to be testing
- done before it hits CVS, and to ensure that all changes are
- appropriate just to fix whatever the problem is.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Do not commit <emphasis>anything</emphasis> unless your proposed
+ changes have been well tested first, preferably by other members of the
+ project, or have prior approval of the project leaders or consensus
+ of the devel list.
+ </para>
+ </listitem>
<listitem>
<para>
Where possible, bugfixes and changes should be tested in the main
Then ask for peer review.
</para>
</listitem>
- <listitem>
- <para>
- Do not commit <emphasis>anything</emphasis> unless your proposed
- changes have been well tested first, by other members of the
- project, and have prior approval of the project leaders or consensus
- of the devel list.
- </para>
- </listitem>
<listitem>
<para>
Do not even think about anything except bugfixes. No new features!
</itemizedlist>
</para>
+ -->
</sect2>
-<!--
- This sounds vague, dated, and out of step with current development style.
- Removing 09/03/02, HB.
-
- <sect2 id="cvswhenask"><title>Discussing Changes First</title>
- <para>
- We don't have a formal policy for the development branch, just use
- common sense. Hints: If it is..
- <orderedlist numeration="arabic">
- <listitem><para>
- ..a bug-fix / clean-up / cosmetic thing: shoot
- </para></listitem>
- <listitem><para>
- ..a new feature that can be turned off: shoot
- </para></listitem>
- <listitem><para>
- ..a clear improvement w/o side effects on other parts of the code: shoot
- </para></listitem>
- <listitem><para>
- ..a matter of taste: <ulink url="mailto:developers@privoxy.org">ask the list</ulink>
- </para></listitem>
- <listitem><para>
- ..a major redesign of some part of the code: <ulink url="mailto:developers@privoxy.org">ask
- the list</ulink>
- </para></listitem>
- </orderedlist>
- </para>
- <para>
- 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 <ulink
- url="http://sourceforge.net/tracker/?atid=311118&group_id=11118&func=browse">patches
- tracker</ulink> instead.
- </para>
- </sect2>
- -->
</sect1>
<!-- ~~~~~ New section ~~~~~ -->
url="../user-manual/index.html"><citetitle>user-manual</citetitle></ulink>,
<ulink url="../faq/index.html"><citetitle>FAQ</citetitle></ulink>, and, of
course this, the <citetitle>developer-manual</citetitle> in this format.
- The <citetitle>README</citetitle>, <citetitle>AUTHORS</citetitle>
+ The <citetitle>README</citetitle>, <citetitle>AUTHORS</citetitle>,
+ <citetitle>INSTALL</citetitle>,
<citetitle>privoxy.1</citetitle> (man page), and
<citetitle>config</citetitle> files are also now maintained as Docbook
SGML. These files, when built, in the top-level source directory are
variation on this file, <filename>privoxy-index.html</filename>,
meant for inclusion with doc packages), are maintained as SGML as well.
<emphasis>DO NOT edit these directly</emphasis>. Edit the SGML source, or
- contact someone involved in the documentation (at present Hal).
+ contact someone involved in the documentation.
</para>
<para>
<filename>config</filename> requires some special handling. The reason it
<filename>config</filename>.
</para>
<para>
- Other, less formal documents (e.g. <filename>LICENSE</filename>,
- <filename>INSTALL</filename>) are maintained as plain text files in the
- top-level source directory. At least for the time being.
+ Other, less formal documents (e.g. <filename>LICENSE</filename>) are
+ maintained as plain text files in the top-level source directory.
</para>
<para>
Packagers are encouraged to include this documentation. For those without
the ability to build the docs locally, text versions of each are kept in
- CVS. HTML versions are also now being kept in CVS under
- <filename>doc/webserver/*</filename>.
+ CVS. HTML versions are also being kept in CVS under
+ <filename>doc/webserver/*</filename>. And PDF version are kept in
+ <filename>doc/pdf/*</filename>.
</para>
<para>
Formal documents are built with the Makefile targets of
<listitem>
<para>
Our documents are available in differing formats. Right now, they
- are just plain text, TML, and PDF, but others are always a
+ are just plain text, HTML, and PDF, but others are always a
future possibility. Be careful with URLs (<ulink>), and avoid
this mistake:
</para>
<para><emphasis>Example for file comments:</emphasis></para>
<programlisting>
-const char FILENAME_rcs[] = "$Id: developer-manual.sgml,v 2.2 2002/09/04 01:55:44 hal9 Exp $";
+const char FILENAME_rcs[] = "$Id: developer-manual.sgml,v 2.7 2006/07/18 14:48:50 david__schmidt Exp $";
/*********************************************************************
*
* File : $S<!-- Break CVS Substitution -->ource$
<programlisting>
#ifndef _FILENAME_H
#define _FILENAME_H
-#define FILENAME_H_VERSION "$Id: developer-manual.sgml,v 2.2 2002/09/04 01:55:44 hal9 Exp $"
+#define FILENAME_H_VERSION "$Id: developer-manual.sgml,v 2.7 2006/07/18 14:48:50 david__schmidt Exp $"
/*********************************************************************
*
* File : $S<!-- Break CVS Substitution -->ource$
This ensures that builds from CVS snapshots are easily distinguished from released versions.
The point version is reset to zero when the minor changes.
</para>
+ <para>
+ Stable branches work a little differently, since there should be
+ little to no development happening in such branches. Remember,
+ only bugfixes, which presumably should have had some testing
+ before being committed. Stable branches will then have their
+ version reported as <literal>0.0.0</literal>, during that period
+ between releases when changes are being added. This is to denote
+ that this code is <emphasis>not for release</emphasis>. Then
+ as the release nears, the version is bumped according: e.g.
+ <literal>3.0.1 -> 0.0.0 -> 3.0.2</literal>.
+ </para>
</listitem>
</itemizedlist>
</para>
In summary, the main CVS trunk is the development branch where new
features are being worked on for the next stable series. This should
almost always be where the most activity takes place. There is always at
- least one stable branch from the trunk, e.g now it is 3.0, which is only
- used to release stable versions. Once the initial .0 release of the
- stable branch has been done, then as a rule, only bugfixes that have had
- prior testing should be committed to the stable branch. At that point, it
- is mostly <quote>hands off</quote>. Once there are enough bugfixes to
- justify a new release, the version of this branch is again incremented
- Example: 3.0.0 -> 3.0.1 -> 3.0.2, etc are all stable releases from within
- the stable branch. 3.1.x is currently the main trunk, and where work on
- 3.2.x is taking place. If any questions, please post to the devel list
+ least one stable branch from the trunk, e.g now it is
+ <literal>3.0</literal>, which is only used to release stable versions.
+ Once the initial *.0 release of the stable branch has been done, then as a
+ rule, only bugfixes that have had prior testing should be committed to
+ the stable branch. Once there are enough bugfixes to justify a new
+ release, the version of this branch is again incremented Example: 3.0.0
+ -> 3.0.1 -> 3.0.2, etc are all stable releases from within the stable
+ branch. 3.1.x is currently the main trunk, and where work on 3.2.x is
+ taking place. If any questions, please post to the devel list
<emphasis>before</emphasis> committing to a stable branch!
-
+ </para>
+ <para>
+ Developers should remember too that if they commit a bugfix to the stable
+ branch, this will more than likely require a separate submission to the
+ main trunk, since these are separate development trees within CVS. If you
+ are working on both, then this would require at least two separate check
+ outs (i.e main trunk, <emphasis>and</emphasis> the stable release branch,
+ which is <literal>v_3_0_branch</literal> at the moment).
</para>
</sect2>
</para>
<para>
<programlisting>
- cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co os2setup
+ cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co os2setup
</programlisting>
</para>
<para>
</para>
<para>
<programlisting>
- cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co winsetup
+ cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co winsetup
</programlisting>
</para>
<para>
</para>
<para>
<programlisting>
- cvs -z3 -d:pserver:anonymous@cvs.ijbswa.sourceforge.net:/cvsroot/ijbswa co osxsetup
+ cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co osxsetup
</programlisting>
</para>
<para>
Temple Place - Suite 330, Boston, MA 02111-1307, USA.
$Log: developer-manual.sgml,v $
- Revision 2.2 2002/09/04 01:55:44 hal9
- Migrating developer manual, and related sgml files from 3.0. Add additional
- commentary on cvs, versioning, stable branches, and how to handle stable
- branches in cvs.
+ Revision 2.7 2006/07/18 14:48:50 david__schmidt
+ Reorganizing the repository: swapping out what was HEAD (the old 3.1 branch)
+ with what was really the latest development (the v_3_0_branch branch)
+
+ Revision 1.46.2.11 2002/12/11 13:12:15 hal9
+ Rewrite cvs write access give-away section.
+
+ Revision 1.46.2.10 2002/09/26 21:53:45 hal9
+ Changes to reflect recent change in stable branch commit policy (hopefully
+ clearer now).
+
+ Revision 1.46.2.9 2002/09/26 01:21:40 hal9
+ Porting 3.1.1 changes: more on cvs and branches, more on versions and
+ releases.
Revision 1.46.2.8 2002/08/17 00:16:10 hal9
Add note on updating webserver for User-manual/CGI editor, which is version
projects / privoxy.git / blobdiff