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:09:48 -0800 (PST)
From: rbb@covalent.net
To: new-httpd@apache.org
Subject: Re: just say no (was: Re: Release Strategy)
In-Reply-To: <20010205115930.A23380@trainedmonkey.com>
Message-ID: <Pine.LNX.4.21.0102051205130.21191-100000@koj>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


> > There are a number of reasons I don't believe this will work.  First of
> > all, just tagging ap_release.h with the new tag means that the build isn't
> > easily reproducable, because you have to check out the whole tree with one
> > tag, then checkout the ap_release.h file with a separate tag.  This is why
> > you much re-tag the entire tree.
> 
> 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.

> okay, that aside, what i wanted to do is explain how php is doing
> its releases now. (i'm not saying it is perfect, but i think it
> addresses the issues that ryan is worried about.)
> 
> to release a version of php, we cut a branch of the then-current
> HEAD (which is where all the real development happens. it is called
> something like php_4_0_4.
> 
> that branch is then tagged and rolled with a name like php-4.0.4rc1.
> it gets announced to the developers and people who have signed up
> for the php-qa list. if bugs are found, fixes are checked in to
> that branch (and HEAD), and another release candidate is tagged and
> rolled. if necessary, the "minimal fix" goes into the 'stabilization'
> branch, and the "more correct but riskier fix" goes into HEAD.
> 
> when there is consensus that the branch is "good enough", it is
> tagged and rolled one last time and released.
> 
> our track record isn't great, so we've also had to release things
> like "4.0.4pl1", which is just a continuation of that 4.0.4 branch.
> 
> but when we go to stabilize and release 4.0.5, it is a branch
> cut from HEAD, not a continuation of the 4.0.4 branch.
> 
> (now, personally, i would change a couple of things -- i'd call
> each branch used for stabilization something like 4.1, and then just
> release each 'release candidate' as 4.1.x. then there's no need to
> do that "one last tag and roll" since you can just announce at some
> point that "4.1.5 is the latest stable release". it also makes use of
> that middle digit, which the php project has failed to ever use. :)
> 
> the difference between this model and the linux/freebsd one is
> that we don't really have this ongoing stable branch that has to be
> synchronized with ongoing development. whenever we go to do a real
> release, we start a new branch from the then-current 'unstable' HEAD.

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.

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.

The whole time, HEAD is continuing to develop, so big changes are still
going in, which means the next release may or may not be as good or better
than the current tarball.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------