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

diff --git a/ROADMAP b/ROADMAP
index ca29bdc4ab82150f331a53751d6906decd01b22b..8d107ba69c9601d75da60f17e3344e3c973e9f72 100644 (file)
--- 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