You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by wr...@apache.org on 2007/07/09 18:45:45 UTC
svn commit: r554702 - /httpd/site/trunk/docs/dev/release.html
Author: wrowe
Date: Mon Jul 9 09:45:43 2007
New Revision: 554702
URL: http://svn.apache.org/viewvc?view=rev&rev=554702
Log:
Regenerated
Modified:
httpd/site/trunk/docs/dev/release.html
Modified: httpd/site/trunk/docs/dev/release.html
URL: http://svn.apache.org/viewvc/httpd/site/trunk/docs/dev/release.html?view=diff&rev=554702&r1=554701&r2=554702
==============================================================================
--- httpd/site/trunk/docs/dev/release.html (original)
+++ httpd/site/trunk/docs/dev/release.html Mon Jul 9 09:45:43 2007
@@ -68,6 +68,13 @@
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>
</blockquote>
</td></tr>
</table>
@@ -79,7 +86,7 @@
</td></tr>
<tr><td>
<blockquote>
-<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="http://www.apache.org/licenses/">Apache Software License</a>.
However, only members of the Apache HTTP Server Project (committers)
can make a release designated with Apache. Other people must
@@ -103,13 +110,12 @@
<blockquote>
<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>
</blockquote>
</td></tr>
</table>
@@ -147,7 +153,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>
</blockquote>
</td></tr>
</table>
@@ -202,7 +208,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 apache.org for
a period of time. This will require coordination with the current
maintainers of apache.org's httpd instance. In the past, the group has
@@ -224,8 +231,8 @@
</td></tr>
<tr><td>
<blockquote>
-<p>Once the tree has been suitably tested by the RM and any other
-interested parties, they should "roll" the release.</p>
+<p>Once the tree has been suitably tested by the RM and any other interested
+parties, they should "roll" a candidate tarball for potential release.</p>
<p>Key points:</p>
<ul>
<li>Ensure that the RM's PGP/GPG key is in the httpd-dist/KEYS file</li>
@@ -234,7 +241,8 @@
<li>Copy the generated release tarballs and signatures to
people.apache.org:/www/httpd.apache.org/dev/dist</li>
<li>Email dev@httpd.apache.org, current-testers@httpd.apache.org and
-stable-testers@httpd.apache.org to inform them of the release.</li>
+stable-testers@httpd.apache.org with a [VOTE] Release X.Y.Z to call for
+testing and votes on this candidate.</li>
</ul>
</blockquote>
</td></tr>
@@ -247,25 +255,32 @@
</td></tr>
<tr><td>
<blockquote>
-<p>At this point, the release is an alpha. The Apache HTTP Server Project
-has three classifications for its releases:</p>
+<p>At this point, this tarball/archive is not yet a release.</p>
+<p>Based on the communities confidence in the code, the next step is
+to issue a release vote as alpha, beta or general availability (GA)
+candidate. The Apache HTTP Server Project has three classifications
+for its releases:</p>
<ul>
<li>Alpha</li>
<li>Beta</li>
<li>General Availability (GA)</li>
</ul>
<p>Alpha indicates that the release is not meant for mainstream usage or
-may have serious problems that prohibits its use. When a release is
-initially created, it automatically becomes alpha quality.</p>
-<p>Beta indicates that at least three committers have voted positively
-for beta status and there were more positive than negative votes for
-beta designation. This indicates that it is expected to compile and
-perform basic tasks. However, there may be problems with this release
-that prohibit its widespread adoption.</p>
-<p>General Availability (GA) indicates that at least three committers
-have voted positively for GA status and that there were more positive
-than negative votes for GA designation. This release is recommended
-for production usage.</p>
+may have serious problems that prohibits its use. The initial releases
+off of the x.{odd}.z development branches are considered alpha quality.</p>
+<p>Beta indicates that the x.{odd}.z development branch is nearing
+completion and will soon ship as a x.{even}.0 GA release. This indicates
+that it is expected to compile and perform basic tasks. However, there
+may be problems with this release that inhibit its widespread adoption.</p>
+<p>General Availability (GA) indicates that this release is the best
+available version and is recommended for all usage. It also indicates
+that this release replaces all previous GA versions, and it's interfaces
+should remain stable throughout the life of this x.y version. (Those
+interfaces that are in flux are designated <i>experimental</i>.)</p>
+<p>Finally, remember version numbers are cheap. If x.y.13 is retracted
+due to a flaw or prior veto or simply because of 'one more change' to add
+to this next release, then the RM should designate x.y.14. Don't attempt
+to overload an earlier tarball with additional changes, simply keep moving.</p>
</blockquote>
</td></tr>
</table>
@@ -277,17 +292,23 @@
</td></tr>
<tr><td>
<blockquote>
+<p>For the ASF to release the prepared tarball/archive, at least three
+project members must vote affirmatively for release, and there must be more
+positive than negative votes for the release. There is no 'veto' to a
+release vote. A previous veto of specific code can and should be called
+out to the RM if it was not honored, and it's the RM's decision to determine
+that the veto included a justification and therefore retract the vote. A new
+tarball release candidate should be rolled without the offending code if this
+is the case.</p>
<p>Non-committers may cast a vote for a release's quality. In fact,
this is extremely encouraged as it provides much-needed feedback to
the community about the release's quality. However, only binding
votes casted by committers count towards the designation.</p>
-<p>Note that no one may veto a release. Releases may not receive a
-designation level if a problem is found that inhibits proper
-functionality. The group may (implicitly or explicitly) revoke all votes
-on a release if there is a problem. However, if there is a -1 vote for
-a particular designation and there are greater than 3 positive votes
-and more positive than negative votes (i.e. majority consensus), the
-appropriate designation is conferred upon the release.</p>
+<p>Finally, note that votes are on <i>source code</i> tarballs, and only the
+source code is authoritative. Binaries, while helpful, are considered
+other artifacts and must be generated from the exact source code contained
+in the release. If a patch is unavoidable for a specific platform, the
+applicable patches MUST be made available alongside the platform binaries.</p>
</blockquote>
</td></tr>
</table>