This file belongs into
ijbswa.sourceforge.net:/home/groups/i/ij/ijbswa/htdocs/
- $Id: developer-manual.sgml,v 2.3 2002/09/05 02:27:59 hal9 Exp $
+ $Id: developer-manual.sgml,v 2.4 2002/09/26 05:57:14 hal9 Exp $
Copyright (C) 2001, 2002 Privoxy Developers <developers@privoxy.org>
See LICENSE.
</pubdate>
- <pubdate>$Id: developer-manual.sgml,v 2.3 2002/09/05 02:27:59 hal9 Exp $</pubdate>
+ <pubdate>$Id: developer-manual.sgml,v 2.4 2002/09/26 05:57:14 hal9 Exp $</pubdate>
<!--
linkend="versionnumbers">Version Numbers</link> below for details on
versioning.)
</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>
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):
+ 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!
<para><emphasis>Example for file comments:</emphasis></para>
<programlisting>
-const char FILENAME_rcs[] = "$Id: developer-manual.sgml,v 2.3 2002/09/05 02:27:59 hal9 Exp $";
+const char FILENAME_rcs[] = "$Id: developer-manual.sgml,v 2.4 2002/09/26 05:57:14 hal9 Exp $";
/*********************************************************************
*
* File : $S<!-- Break CVS Substitution -->ource$
<programlisting>
#ifndef _FILENAME_H
#define _FILENAME_H
-#define FILENAME_H_VERSION "$Id: developer-manual.sgml,v 2.3 2002/09/05 02:27:59 hal9 Exp $"
+#define FILENAME_H_VERSION "$Id: developer-manual.sgml,v 2.4 2002/09/26 05:57:14 hal9 Exp $"
/*********************************************************************
*
* File : $S<!-- Break CVS Substitution -->ource$
<para>
First you need to determine which version number the release will have.
<application>Privoxy</application> version numbers consist of three numbers,
- separated by dots, like in X.Y.Z (e.g. 3.0.0), where:
+ separated by dots, like in X.Y.Z (e.g. <literal>3.0.0</literal>), where:
<itemizedlist>
<listitem>
<para>
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>
Temple Place - Suite 330, Boston, MA 02111-1307, USA.
$Log: developer-manual.sgml,v $
+ Revision 2.4 2002/09/26 05:57:14 hal9
+ Conditionally exclude 'this doc is evolving' comment in intro for non release
+ situations.
+
Revision 2.3 2002/09/05 02:27:59 hal9
Mention tested stable branch fixes in main trunk, as alternate to posting
patches.
projects / privoxy.git / blobdiff