httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: Release Strategy
Date Mon, 05 Feb 2001 20:20:13 GMT
> As I said, the name was probably wrong.  I do see a reason to re-tag as
> well.  The re-tag is done after updating ap_release.h.  If we don't re-tag
> after we update ap_release.h, then it will not be possible to easily
> checkout a server that has the correct server version string.  This is
> also why I want to use the date for the tag from now on, I believe the
> date gives more information than just a new number.

Let's simplify this.  My goal is for the quality of a release to be
determined after the tarball is made, and to stop treating minor
version changes as being significant.  I would also prefer that the
build process (post-tag) be automated to the point where the RM can
say (on

   % build_httpd_release httpd-2.0 APACHE_2_0_8 beta

and have the result be a complete apache_httpd_2_0_8_beta.tar.gz.

The only place that "alpha", "beta", "gold", etc., would appear is in
the name of the tarball file and the description on our site.
It cannot appear anywhere in the source code.  I do not want it to
appear in the Server version string, since that requires changing
the tarball after testing.

I don't think we need a bunch of different tags.  To simplify this,
we can just stick with the current process of having the RM bump
ap_release.h before and after tagging, or simply have the RM retag
ap_release.h after bumping it.  If it becomes necessary to branch
the tree in order to make minor fixes to a release, then we branch
on the version tag and merge back on the next point revision.


View raw message