httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Winstead <j...@trainedmonkey.com>
Subject Re: Release Strategy
Date Mon, 05 Feb 2001 18:00:23 GMT
On Mon, Feb 05, 2001 at 06:55:19AM -0800, rbb@covalent.net wrote:
> There are two numbering systems remember.  The first is what we show the
> outside world.  The second is in ap_release.h, and it does leak between
> alpha, beta, and release.  This number is currently called
> APACHE_RELEASE.  If we are going to get rid of this number, we need to
> decide that.

actually, what i think roy was getting at is that there aren't two
numbering systems. you just keep numbering the releases (2.0.0,
2.0.1, 2.0.2, etc) which will have the corresponding value in
APACHE_RELEASE, and then you just label the tarball (or just move
it into the correct directory under dist). the version used in
the server header doesn't change.

i understand this can be tough for people stuck in the
alpha/beta/whatever mentality to wrap their heads around. on
the last big software package i worked on (an educational game),
i instituted a process very similar to what i think roy has proposed.

the standard process at the company was more traditional (alpha 1,
alpha 2, .., beta 1, beta 2, .. , release candidate 1, release
candidate 2, ..).  i just numbered the builds, starting with the
very first one i ever did (build 0).

it drove some people nuts. we released build 200 or so to
manufacturing (and then we used build/patch 220 for fixing up the
online play), since i did builds often, 'skipping' numbers when i
found problems after i had tagged and before i released it to anyone.

but instead of the development group suddenly saying "we think
this is beta 1", the qa department got to say "build 100 meets the
criteria for beta".

> Yeah, but that was a dev tree.  I would have a lot less trouble doing this
> if we had a dev tree and a stable tree.  I believe that is where we are
> headed, but that is going to require the new CVS tree to be added.

use branches. i know they get a bad rap around here from some people,
but putting things in seperate repositories is just ignoring the
tools that cvs provides to make things easier.

but i would really go without seperate trees/branches for a little
while just to see how it goes. the worst that happens is that you
do a few tag&rolls that couldn't even be considered alpha-quality.
if you at least do a test compile before you tag, you can avoid even
tagging builds that would be totally broken. (but you'll still end
up with things like the os/2 build being broken, sometimes.)

> What this also means, is that the httpd-2.0 tree is only frozen for the
> ten minutes it takes to tag the tree, I only suggest that, so that CVS
> doesn't get screwed up.  If we know that we can tag in the middle of
> somebody committing, then this freeze isn't required.  The
> httpd-2.0-stable tree is frozen always, but a merge from httpd-2.0 is
> allowed at any time, assuming the feature is fully tested in httpd-2.0.

why does the tree ever have to be "frozen", even for ten minutes?
as long as you're doing a "cvs tag" of a checkout and not a "cvs
rtag -r HEAD", you'll never collide with checkins that happen after
you've done your checkout but before you've tagged. they'll just
end up being part of the next tag&roll. no big deal when that
happens on a reliable schedule.

jim

Mime
View raw message