From 10edce662c9e76cc41ddf3340cd21a567562614e Mon Sep 17 00:00:00 2001
From: hal9 <hal9@users.sourceforge.net>
Date: Thu, 5 Sep 2002 02:27:59 +0000
Subject: [PATCH] Mention tested stable branch fixes in main trunk, as
alternate to posting patches.
---
doc/source/developer-manual.sgml | 57 ++++++++++++++++++++------------
1 file changed, 36 insertions(+), 21 deletions(-)
diff --git a/doc/source/developer-manual.sgml b/doc/source/developer-manual.sgml
index b8d762aa..282dd724 100644
--- a/doc/source/developer-manual.sgml
+++ b/doc/source/developer-manual.sgml
@@ -23,7 +23,7 @@
This file belongs into
ijbswa.sourceforge.net:/home/groups/i/ij/ijbswa/htdocs/
- $Id: developer-manual.sgml,v 2.1 2002/07/29 22:08:40 jongfoster Exp $
+ $Id: developer-manual.sgml,v 2.2 2002/09/04 01:55:44 hal9 Exp $
Copyright (C) 2001, 2002 Privoxy Developers <developers@privoxy.org>
See LICENSE.
@@ -48,7 +48,7 @@
</pubdate>
- <pubdate>$Id: developer-manual.sgml,v 1.46.2.8 2002/08/17 00:16:10 hal9 Exp $</pubdate>
+ <pubdate>$Id: developer-manual.sgml,v 2.2 2002/09/04 01:55:44 hal9 Exp $</pubdate>
<!--
@@ -189,11 +189,12 @@ Hal.
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).
- 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
+ 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
linkend="versionnumbers">Version Numbers</link> below for details on
versioning.)
</para>
@@ -250,10 +251,10 @@ Hal.
</para>
<para>
- 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
- v_3_0_branchpoint branch):
+ 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):
</para>
<para>
@@ -263,20 +264,29 @@ Hal.
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>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Where possible, bugfixes and changes should be tested in the main
+ development trunk first. There may be occasions where this is not
+ feasible, though.
+ </para>
+ </listitem>
<listitem>
<para>
- Submit any proposed changes as patches first to the patch tracker on
- Sourceforge: <ulink url="http://sourceforge.net/tracker/?group_id=11118&atid=311118">http://sourceforge.net/tracker/?group_id=11118&atid=311118</ulink>.
- Then ask for peer review.
+ Alternately, proposed changes can be submitted as patches to the patch tracker on
+ Sourceforge first: <ulink
+ url="http://sourceforge.net/tracker/?group_id=11118&atid=311118">http://sourceforge.net/tracker/?group_id=11118&atid=311118</ulink>.
+ Then ask for peer review.
</para>
</listitem>
<listitem>
<para>
- Do not commit <emphasis>anything</emphasis> unless your patches
- been well tested first, by other members of the project,
- and has prior approval of the project leaders or consensus of the
- devel list.
+ 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>
@@ -1833,7 +1843,7 @@ static void unload_re_filterfile( void *f ) { ... }</programlisting>
<para><emphasis>Example for file comments:</emphasis></para>
<programlisting>
-const char FILENAME_rcs[] = "$Id: developer-manual.sgml,v 1.46.2.8 2002/08/17 00:16:10 hal9 Exp $";
+const char FILENAME_rcs[] = "$Id: developer-manual.sgml,v 2.2 2002/09/04 01:55:44 hal9 Exp $";
/*********************************************************************
*
* File : $S<!-- Break CVS Substitution -->ource$
@@ -1893,7 +1903,7 @@ const char FILENAME_h_rcs[] = FILENAME_H_VERSION;
<programlisting>
#ifndef _FILENAME_H
#define _FILENAME_H
-#define FILENAME_H_VERSION "$Id: developer-manual.sgml,v 1.46.2.8 2002/08/17 00:16:10 hal9 Exp $"
+#define FILENAME_H_VERSION "$Id: developer-manual.sgml,v 2.2 2002/09/04 01:55:44 hal9 Exp $"
/*********************************************************************
*
* File : $S<!-- Break CVS Substitution -->ource$
@@ -2987,6 +2997,11 @@ at sourceforge. Three simple steps:
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 1.46.2.8 2002/08/17 00:16:10 hal9
Add note on updating webserver for User-manual/CGI editor, which is version
dependent (and different from main UM link).
--
2.49.0