You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-cvs@httpd.apache.org by jo...@apache.org on 2005/05/16 17:18:23 UTC

svn commit: r170399 - /httpd/apreq/trunk/FAQ.pod

Author: joes
Date: Mon May 16 08:18:22 2005
New Revision: 170399

URL: http://svn.apache.org/viewcvs?rev=170399&view=rev
Log:
Add notes for managing stable trees, since 2.06 will lead us there.

Modified:
    httpd/apreq/trunk/FAQ.pod

Modified: httpd/apreq/trunk/FAQ.pod
URL: http://svn.apache.org/viewcvs/httpd/apreq/trunk/FAQ.pod?rev=170399&r1=170398&r2=170399&view=diff
==============================================================================
--- httpd/apreq/trunk/FAQ.pod (original)
+++ httpd/apreq/trunk/FAQ.pod Mon May 16 08:18:22 2005
@@ -3,7 +3,11 @@
 [...]
 
 
-=head1 Using libapreq2 with Apache 2 and mod_perl 2.
+
+
+=head1 Using libapreq2 with Apache2 and mod_perl2.
+
+
 
 
 =head2 When I use Apache::Request in my output filter, it seems to lose the incoming POST variables.
@@ -29,6 +33,34 @@
 C<use Apache::Upload> to load the C<Apache::Request::upload> function.
 
 
+
+
 =head1 Using libapreq2 outside of Apache.
 
 [...]
+
+
+
+
+=head1 Contributing to apreq development.
+
+
+
+
+=head2 How is the subversion repository managed?
+
+apreq's repository is broken into three subdirectories:
+
+        /trunk    - the current codebase for active development.
+        /tags     - release snapshots.
+        /branches - where older releases and experimental development lines live.
+
+apreq follows a Commit-then-Review policy for its entire repository,
+but being a shared library places certain restrictions on the admissible
+changes for stable trees.   Basically the header files cannot be modified;
+only new functions and structures may be added to them.  Any time that 
+happens, the minor-version needs to be bumped, and the patch-level gets
+reset to zero.  Changes that only modify the library's implementation (.c)
+files require a bump to the patch-level.  On stable trees, this version 
+tracking should happen on each commit, to make auditing easy for other 
+developers without resorting to a draconian Review-then-Commit policy.