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:41:49 -0800
From: Greg Stein <gstein@lyra.org>
To: new-httpd@apache.org
Subject: Re: just say no (was: Re: Release Strategy)
Message-ID: <20010205124149.J26044@lyra.org>
Mail-Followup-To: 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.2i
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:
> > > 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.

Agreed. That needs to be changed, and it is desirable (required?) for it to
be within CVS itself, under some name. [we'll just assume "required" for now]

Okay... you don't need to do a checkout with two tags. Yes, that would be
painful.

$ cvs checkout http-2.0

[ build. prelim test. seems reasonable. ]

$ cvs tag APACHE_2_0_11

[ tags based on what is in the *working* directory; while the person did the
  build and prelim test, other people were checking stuff in. that doesn't
  get tagged. ]

$ tar czf the-tarball

--- several days later ---

[ assuming a new working directory; this first isn't needed if the working
  dir was kept from before ]
$ cvs checkout -rAPACHE_2_0_11 httpd-2.0
$ edit include/ap_release.h
$ cvs commit include/ap_release.h
$ cvs tag APACHE_2_0_11_beta


The second tag just goes over the whole tree. No need to restrict it to
ap_release.h.

[ there may be some tweaky changes to the above recipe; the checkout will do
  a "sticky" tag, so I'm not exactly sure how that commit will behave. I did
  a little test with "checkout -A" to try to avoid the sticky tags; didn't
  do what I expected, so some reading would be needed. but the main point
  here: the alpha/beta/whatever tag goes on the *whole* tree; not just
  ap_release.h. my original point is that only ap_release.h changes when we
  update the release status. only that one file needs to be forked. ]

>...
> 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.

Whenever the RM feels like it, actually. We know the last tarball is dead,
so we can wait for the OS/2 fixes and roll a new one right after that
commit. No schedules are needed.  Read: flexibility :-)

> 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.

Right!

> 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.

Yup!

Now. Let's say the tarball is broken, with just a couple minor things. We
don't patch it. We just throw it out and wait for the next tarball to be
built. If big changes were occurring, then it might be a bit longer.

We don't want to start maintaining branches (or worse: separate trees). If
somebody doesn't work, we punt and try again later.

We are all motivated to get a release out, so I don't think there will be
gratuitous changes if we all know we're "close". But we also don't want to
return to a "heavy" process that would involved branches or trees.

"Doesn't work? Oh well. Maybe the next one will."

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/