Add technique for dealing with major version bumps.

(i.e. lazily resolve them when we go to create a new stable tree)


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@97264 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 9 insertions, 1 deletions

diff --git a/ROADMAP b/ROADMAP
index ca29bdc4ab..8d107ba69c 100644
--- a/ROADMAP
+++ b/ROADMAP
@@ -1,6 +1,6 @@
 APACHE 2.x ROADMAP
 ==================
-Last modified at [$Date: 2002/10/19 17:30:15 $]
+Last modified at [$Date: 2002/10/19 17:41:51 $]
 
 
 INTRODUCTION
@@ -133,6 +133,14 @@ begun, that API will be present for the lifetime of the stable release.  Any
 desired changes in the stable versions must wait for inclusion into the next
 release cycle.
 
+When deciding to promote a development tree to being stable, a determination
+should be made whether the changes since the last stable version warrant a
+major version bump.  That is, if 2.2 is the current stable version and 2.3 is
+'ready' to become stable, the group needs to decide if the next stable
+version is 2.4 or 3.0.  One suggested rule of thumb is that if it requires
+too much effort to port a module from 2.2 to 2.4, then the stable version
+should be labeled 3.0.
+
 In order to ease the burden of creating development releases, the process
 for packaging a development releases is less formal than for the stable
 release.  This strategy reflects the fact that while in development, versions