From: hal9 <hal9@users.sourceforge.net>
Date: Thu, 26 Sep 2002 21:50:39 +0000 (+0000)
Subject: Changes to reflect recent change in stable branch commit policy (hopefully
X-Git-Tag: v_3_1_archive_branchpoint~109
X-Git-Url: http://www.privoxy.org/gitweb/?p=privoxy.git;a=commitdiff_plain;h=bfa3ce8efad9c76a94bc2a2492b46c259c087636

Changes to reflect recent change in stable branch commit policy (hopefully
clearer now).
---

diff --git a/doc/source/developer-manual.sgml b/doc/source/developer-manual.sgml
index dfe6cc70..33a73371 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.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.
@@ -48,7 +48,7 @@
     </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>
 
 <!--
 
@@ -199,6 +199,15 @@ Hal.
        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>
@@ -255,18 +264,19 @@ Hal.
        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 
@@ -282,14 +292,6 @@ Hal.
           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!
@@ -1844,7 +1846,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 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$
@@ -1904,7 +1906,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 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$
@@ -2082,7 +2084,7 @@ at sourceforge. Three simple steps:
     <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>
@@ -2121,6 +2123,17 @@ at sourceforge. Three simple steps:
               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>
@@ -2128,17 +2141,24 @@ at sourceforge. Three simple steps:
      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>
@@ -2998,6 +3018,10 @@ at sourceforge. Three simple steps:
   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.