From e56bb958eace8898de6853bb02a6aedcf0bbaacc Mon Sep 17 00:00:00 2001 From: Justin Erenkrantz Date: Sat, 19 Oct 2002 17:41:51 +0000 Subject: [PATCH] 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 --- ROADMAP | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) 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 -- 2.50.1