httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r554685 - /httpd/site/trunk/xdocs/dev/release.xml
Date Mon, 09 Jul 2007 15:37:39 GMT
Author: wrowe
Date: Mon Jul  9 08:37:38 2007
New Revision: 554685

Revert 2.0.x generation changes that were invalid.  All releases
require a vote and approval by the project members.

(Anything without three +1's is nothing but a snapshot by another name.)


Modified: httpd/site/trunk/xdocs/dev/release.xml
--- httpd/site/trunk/xdocs/dev/release.xml (original)
+++ httpd/site/trunk/xdocs/dev/release.xml Mon Jul  9 08:37:38 2007
@@ -11,10 +11,18 @@
 Apache HTTP Server Project to create releases of httpd-2.0 (the current
 Apache 2.0 branch).  As described herein, this policy is not set in stone
 and may be adjusted by the Release Manager.</p>
+<p>With the introduction of Apache 2.1, the Apache httpd project has
+adopted an odd-even release strategy, where development happens with
+alpha and beta releases assigned an odd-numbered minor version, and its
+general availability (stable) release is designed with the subsequent
+even-numbered minor version.  E.g. 2.1.0-alpha through 2.1.6-alpha
+were followed by 2.1.7-beta through 2.1.9 beta, and cumulated in the
+2.2.0 general availability release.<p>
 <section><title>Who can make a release?</title>
-<p>Technically, any one can make a release of the source code due to the
+<p>Technically, anyone can make a release of the source code due to the
 <a href="">Apache Software License</a>.
 However, only members of the Apache HTTP Server Project (committers)
 can make a release designated with Apache.  Other people must
@@ -31,13 +39,12 @@
 <section><title>Who is in charge of a release?</title>
 <p>The release is coordinated by the Release Manager (hereafter, abbreviated
 as RM).  Since this job requires coordination of the development community
-(and access to CVS), only committers to the project can be RM.  However,
+(and access to subversion), only committers to the project can be RM.  However,
 there is no set RM.  Any committer may perform a release at any time.  In
 order to facilitate communication, it is deemed nice to alert the
 community with your planned release schedule before executing the
 release.  A release should only be made when there is a plan to publicly
-release it.  (A release should not be made only for private distribution.
-A private release is more suitable for that.)</p>
+release it.  (A release must not be made only for private distribution).</p>
 <section><title>Who may make a good candidate for an RM?</title>
@@ -59,7 +66,7 @@
 entry is resolved.  These items may be bugs, outstanding vetos that have
 not yet been resolved, or enhancements that must make it into the
 release.  Note that the RM may also add showstopper entries to indicate
-what issues must be resolved before a release may be created.</p>
+what issues must be resolved before they intend to create a release.</p>
 <section><title>What power does the RM yield?</title>
@@ -91,7 +98,8 @@
 <p>The RM may perform sanity checks on release candidates.  One highly
 recommended suggestion is to run the httpd-test suite against the candidate.
 The release candidate should pass all of the relevant tests before making
-it official.</p>
+it official, and certainly avoid new regressions (tests that previously
+passed, and now fail).</p>
 <p>Another good idea is to coordinate running a candidate on for
 a period of time.  This will require coordination with the current

View raw message