httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject RE: Release Strategy
Date Mon, 05 Feb 2001 16:15:44 GMT

[ Moving this back on-list to let everybody comment. ]

On Mon, 5 Feb 2001, Padwa, Daniel wrote:

> Why would you build a separate repository instead of using CVS tags to
> handle this?

I like the separate repository, because it separates the two trees a bit
more.  I guess my question for you is how do you move a single change to
STABLE if there is another change in the same file that you don't want to
move to STABLE?  This would be possible if we branched the tree, but there
are a lot of people on this list who really dislike the idea of branching.

> 
> In projects here we use something like a STABLE tag.   Rules of engagement
> are:
> 
> HEAD:
> 	checkin as you please
> 	must (almost always) compile cleanly
> 
> STABLE:
> 	promote things to stable as you are confident in them (could put
> lots of 	process around this step, but usually makes sense to trust
> developers).
> 
> 	always a manual process - rarely hurts to ask developers to
> double-check their
> 	own work before declaring it stable.
> 
> 	must be stable (compile and feature-wise) everywhere, or be fixed
> ASAP
> 
> 
> You can do nightly tag/rolls of STABLE....getting the version string right
> could be as simple as having the build job create a new ap_version.c, check
> it in, and tag it.

Yeah, that is what the ap_release.h file is for.

> When you get close to release, you can tag one of the nightly builds with a
> RELEASE_CANDIDATE tag (or something like that).   You can then add in a few
> other files (or later revisions) to that candidate by just applying the tag.
> Branch as necessary and you're set.
> 
> Nice thing about this approach is that it lets developers develop (on HEAD).
> It lets a stable level remain stable - code doesn't get added to STABLE
> until someone says that it should.    It lets releases stabilize quickly -
> whomever is doing final touch-up of a major release should have sole
> authority to tag things into the release.   Or you can have the whole team
> tag stuff in at first, and then lock it down in the last day before a
> release.

This is the exact idea that I am going for.  I think the only difference
is that I am suggesting two trees and you are suggesting one.  The biggest
reason I like two trees, is that I don't see how to do it with one tree
without branching, and I know that everytime branching comes up as an
idea, there are people on this list who express intense dislike for that
option.

> Feel free to share any of this with the list - I'm sending it to you direct
> since this seemed a bit large for a post from someone who mostly lurks.

I sent it all to the list.  Lurkers sometimes have the best ideas, and I
would rather get this done in public.

> 
> - Danny


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



Mime
View raw message