Author: hwright
Date: Tue Jun 28 03:04:31 2011
New Revision: 1140415
URL: http://svn.apache.org/viewvc?rev=1140415&view=rev
Log:
Release docs: use a table to better communicate the various pre-release types,
and remove existing now-superfluous text.
* docs/community-guide/releasing.part.html
(release-numbering): Add table, adjust text here, and when talking about
alphas and betas.
Modified:
subversion/site/publish/docs/community-guide/releasing.part.html
Modified: subversion/site/publish/docs/community-guide/releasing.part.html
URL:
http://svn.apache.org/viewvc/subversion/site/publish/docs/community-guide/releasing.part.html?rev=1140415&r1=1140414&r2=1140415&view=diff
==============================================================================
--- subversion/site/publish/docs/community-guide/releasing.part.html (original)
+++ subversion/site/publish/docs/community-guide/releasing.part.html Tue Jun 28
03:04:31 2011
@@ -57,35 +57,43 @@ because eventually we declare a patch li
upgrade to the next minor release, so over the long run the numbering
is basically linear.</p>
-<p>Non-stable releases are qualified with "alphaN" or "betaN"
-suffixes, and release candidates with "-rcN". For example, the
-prereleases leading to 1.3.7 might look like this:</p>
+<p>Subversion releases may be qualified by text following the
+version number, which all represent various steps in the pre-release process.
+In order from least- to most-stable:</p>
+
+<table border="1" cellspacing="2" cellpadding="2">
+<tr>
+ <th>Qualifier</th>
+ <th>Meaning</th>
+ <th>Example</th>
+ <th>Output of <tt>svn --version</tt></th>
+</tr>
+<tr>
+ <td>Alpha</td>
+ <td>We know or expect there to be problems, but solicit testing from
+ interested individuals.</td>
+ <td><tt>subversion-1.7.0-alpha2</tt></td>
+ <td>version 1.7.0 (Alpha 2)</td>
+</tr>
+<tr>
+ <td>Beta</td>
+ <td>We don't expect there to be problems, but be wary just in case.</td>
+ <td><tt>subversion-1.7.0-beta1</tt></td>
+ <td>version 1.7.0 (Beta 2)</td>
+</tr>
+<tr>
+ <td>RC (Release Candidate)</td>
+ <td>This release is a candidate to become the final proposed version. If
+ no serious bugs are found, the <tt>-rc</tt> tag will be dropped, and
+ the contents of this release will be declared stable.</td>
+ <td><tt>subversion-1.7.0-rc4</tt></td>
+ <td>version 1.7.0 (Release Candidate 4)</td>
+</tr>
+</table>
-<pre>
- subversion-1.3.7-alpha1.tar.gz
- subversion-1.3.7-alpha2.tar.gz
- subversion-1.3.7-beta1.tar.gz
- subversion-1.3.7-rc1.tar.gz
- subversion-1.3.7-rc2.tar.gz
- subversion-1.3.7-rc3.tar.gz
- subversion-1.3.7.tar.gz
-</pre>
-
-<p>The output of 'svn --version' corresponds in the obvious way:</p>
-
-<pre>
- version 1.3.7 (Alpha 1)
- version 1.3.7 (Alpha 2)
- version 1.3.7 (Beta 1)
- version 1.3.7 (Release Candidate 1)
- version 1.3.7 (Release Candidate 2)
- version 1.3.7 (Release Candidate 3)
- version 1.3.7
-</pre>
-
-<p>When you '<tt>make install</tt>' subversion-1.3.7-rc1,
+<p>When you '<tt>make install</tt>' subversion-1.7.0-rc1,
it still installs as
-though it were "1.3.7", of course. The qualifiers are metadata on the
+though it were "1.7.0", of course. The qualifiers are metadata on the
release; we want each subsequent prerelease release to overwrite the
previous one, and the final release to overwrite the last
prerelease.</p>
@@ -94,7 +102,7 @@ prerelease.</p>
but '<tt>svn --version</tt>' still produces special output:</p>
<pre>
- version 1.3.8-dev (under development)
+ version 1.7.1-dev (under development)
</pre>
<p>The version number is the next version that project is working
@@ -117,10 +125,7 @@ looking to run the bleeding edger, or te
<p>When we want new features to get wide testing before we enter the
formal stabilization period described above, we'll sometimes release
-alpha and beta tarballs (as <a href="<!--#echo var="GUIDE_RELEASING_PAGE"
-->#release-numbering" >shown
-earlier</a>). The line between alpha and beta is fuzzy, but
-basically, "alpha" means "we know or expect there are problems", and
-"beta" means "we don't expect problems". There is no requirement to
+alpha and beta tarballs. There is no requirement to
do any beta releases even if there were "alpha1", "alpha2", etc
releases; we could just jump straight to "rc1". However, there are
circumstances where a beta can be useful: for example, if we're unsure
