Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Mon, 5 Feb 2001 12:36:43 -0800
From: Jim Winstead <jimw@trainedmonkey.com>
To: new-httpd@apache.org
Subject: Re: just say no (was: Re: Release Strategy)
Message-ID: <20010205123643.A23415@trainedmonkey.com>
Mail-Followup-To: Jim Winstead <jimw@trainedmonkey.com>,
	new-httpd@apache.org
References: <20010205115930.A23380@trainedmonkey.com>
 <Pine.LNX.4.21.0102051205130.21191-100000@koj>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
In-Reply-To: <Pine.LNX.4.21.0102051205130.21191-100000@koj>;
 from rbb@covalent.net on Mon, Feb 05, 2001 at 12:09:48PM -0800

On Mon, Feb 05, 2001 at 12:09:48PM -0800, rbb@covalent.net wrote:
> > side issue -- what is in ap_release.h that needs to get bumped when
> > the classification of a release goes from 'alpha' to 'beta' to
> > 'whatever'? is it really necessary?
> 
> The server string gets changed.  IMHO, yes this is important.

really? i wouldn't have thought anyone really cared that the
server header said "2.0.8alpha" instead of "2.0.8". i'm willing
to accept being in the minority on that, though. :)

> This is very similar to the model that I was suggesting.  I suggested
> using a different tree instead of a branch, just because of the issues
> people here have with branches.

with what i think is an important difference, actually -- each of
these stabilization branches dies very quickly. what you suggested
is a long-lived branch/tree that is continually synced with HEAD. i
see a lot more opportunity for that to get confused and out of sync.

(then again, this is exactly what the freebsd project and linux
kernel do, and they seem to do okay.)

> My understanding of how other people want to do this (and it is VERY
> possible that I am mis-understanding), is that we tag and roll once a
> week.  Each week, that tarball is tested and then we decide what type of
> release it is.  That tarball is at this point dead.  It's release type may
> change, but the code doesn't from this point on.  By that I mean, that we
> may discover after much more testing that this release is more stable than
> initially thought, so we bump it to GA from beta, or vice-versa.  Either
> way, at this point, the code is stable and unmodifiable.

sounds perfectly reasonable to me. the process used by the php
group is definitely somewhere between apache's current process and
this other extreme. it addresses (the reasonable, although also
reasonably deemed unimportant) concern that it be possible to do
a release, then fix just a few minor things, and release that,
without having to worry about other changes going on in HEAD.

it is probably a more important concern in a project like php where
we've got a relatively huge codebase with all the various extensions,
which makes it difficult to even have a minimal level of confidence
that a given snapshot of HEAD will work for a reasonable percentage
of people.

i didn't mean to suggest that the way php does things is what others
are proposing or is the right way to do things for apache. i mainly
brought it up as an example of how short-lived branches are used
to manage the release process.

jim