Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Wed, 16 Oct 2002 21:49:05 -0700
From: Justin Erenkrantz <jerenkrantz@apache.org>
Reply-To: Justin Erenkrantz <jerenkrantz@apache.org>
To: dev@httpd.apache.org
Subject: RE: stable 2.0 trees
Message-ID: <2147483647.1034804945@[10.0.1.6]>
In-Reply-To: <JHEPKCEMGPKFFDHHDDKDAEDHFLAA.bill@wstoddard.com>
References: <JHEPKCEMGPKFFDHHDDKDAEDHFLAA.bill@wstoddard.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

> At the risk of racing too far ahead in this discussion, here is my
> suggestion... 2.0.43 becomes 2.1 and the MMN major does not change
> for subsequent 2.1 series releases (except for a compelling reason,
> eg a security fix -requires- a bump).  Why 2.1?  No technical
> reason; purely a PR tactic to telegraph to the user community we
> are putting a lot of focus on maintaining binary backward
> compatability and to get rid of the *.0.* in the version number
> (yea, to appease the folks who are allergic to 0's in version
> numbers).

Here's my fundamental concern: where do we do the bulk of development 
(new features)?  Do we no longer have 2.0 releases?  Do we close 2.1 
to new features (only security fixes)?  More precisely, who dictates 
what goes into 2.1 or 3.0?

If the sole criteria is MMN bump, the auth changes didn't cause a 
bump of the MMN.  So, then, does it belong in 2.1?  When can we 
remove (or rename) a module - is that a version bump?  What if we add 
a module - version bump?  What if APR changes a function prototype - 
does that require a version bump?  What if we change the meaning of a 
directive (say TAKE12 to TAKE1)?  What if we add (or delete) a 
directive?

If we decide to split off 2.0 into two trees (2.1/3.0 as you 
suggest), then what is the criteria for 3.0 supplanting 2.1?  What is 
the expected lifetime of 2.1?  What is the expected lifetime of 3.0? 
Should we expect a 2.2?  What is the policy for backporting fixes? 
What is the policy for forwardporting fixes?  (Surely no one can 
suggest that 2.0 is bug-free.)  Do you wish to allocate resources for 
maintaining each branch (a la Linux which has open 2.2/2.4/2.5 trees 
and a dedicated maintainer for each)?

I'd prefer to come up with strict versioning rules for httpd before 
proceeding further.  I'm slightly concerned that we're starting to 
move away from the 'versions are cheap' ideology.  Currently, we 
place no meaning on the version numbers (only the quality of the 
tarball).  I think we ought to step back and place a meaning on the 
versions first.  -- justin