Author: hwright
Date: Tue Jun 28 02:28:40 2011
New Revision: 1140404
URL: http://svn.apache.org/viewvc?rev=1140404&view=rev
Log:
Add some text to the release docs about our nightly tarballs, and move the
section on alphas and betas closer to the bit about release numbering.
(That whole section on release numbering could stand a good rewrite /
condensing.)
* publish/docs/community-guide/releasing.part.html
(release-numbering): Talk about the nightlies.
(alphas-betas): Move this section into the bit about release numbering.
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=1140404&r1=1140403&r2=1140404&view=diff
==============================================================================
--- subversion/site/publish/docs/community-guide/releasing.part.html (original)
+++ subversion/site/publish/docs/community-guide/releasing.part.html Tue Jun 28
02:28:40 2011
@@ -172,9 +172,6 @@ prereleases leading to 1.3.7 might look
version 1.3.7
</pre>
-<p>(See <a href="<!--#echo var="GUIDE_RELEASING_PAGE" -->#alphas-betas">this
section</a> for more information
-about when and how we do alpha and beta releases.)</p>
-
<p>When you '<tt>make install</tt>' subversion-1.3.7-rc1,
it still installs as
though it were "1.3.7", of course. The qualifiers are metadata on the
@@ -195,9 +192,47 @@ This indicates
that the build came from a working copy, which is useful in bug
reports.</p>
-<p>We have no mechanism for releasing dated snapshots. If we want
-code to get wider distribution than just those who build from working
-copies, we put out a prerelease.</p>
+<p>We also produce a set of release-like tarballs from the trunk development
+line
+<a href="http://ci.apache.org/projects/subversion/nightlies/index.html";>every
+night</a>, but these have no testing and are only recommended for users
+looking to run the bleeding edger, or test a particular bug fix.</p>
+
+<div class="h4" id="alphas-betas">
+<h4>Alpha and beta releases
+ <a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE"
-->#alphas-betas"
+ title="Link to this section">¶</a>
+</h4>
+
+<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
+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
+of a UI decision and want to get wider user feedback before
+solidifying it into a formal release candidate.</p>
+
+<p>Alphas and betas are only for people who want to help test, and who
+understand that there may be UI- or API-incompatible changes before
+the final release. The signature requirements are at the release
+manager's discretion. Typically, the RM will require only 1 or 2
+signatures for each platform, and to tell signers that they can still
+sign even if their testing reveals minor failures, as long as they
+think the code is solid enough to make testing by others worthwhile.
+The RM should request that signers include a description of any errors
+along with their signatures, so the problems can be published when the
+alpha or beta release is announced.</p>
+
+<p>When the alpha or beta is publicly announced, distribution packagers
+should be firmly warned off packaging it. See <a
+href="http://subversion.tigris.org/servlets/ReadMsg?list=announce&msgNo=264";
+>this mail from Hyrum K. Wright</a> for a good model.</p>
+
+</div> <!-- alphas-betas -->
<div class="h4" id="name-reuse">
<h4>Reuse of release names
@@ -512,42 +547,6 @@ directory.</p>
<p>NOTE: Changes to <tt>STATUS</tt> regarding the temporary branch, including
voting, are always kept on the main release branch.</p>
-<div class="h3" id="alphas-betas">
-<h2>Alpha and beta releases
- <a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE"
-->#alphas-betas"
- title="Link to this section">¶</a>
-</h2>
-
-<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
-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
-of a UI decision and want to get wider user feedback before
-solidifying it into a formal release candidate.</p>
-
-<p>Alphas and betas are only for people who want to help test, and who
-understand that there may be UI- or API-incompatible changes before
-the final release. The signature requirements are at the release
-manager's discretion. Typically, the RM will require only 1 or 2
-signatures for each platform, and to tell signers that they can still
-sign even if their testing reveals minor failures, as long as they
-think the code is solid enough to make testing by others worthwhile.
-The RM should request that signers include a description of any errors
-along with their signatures, so the problems can be published when the
-alpha or beta release is announced.</p>
-
-<p>When the alpha or beta is publicly announced, distribution packagers
-should be firmly warned off packaging it. See <a
-href="http://subversion.tigris.org/servlets/ReadMsg?list=announce&msgNo=264";
->this mail from Hyrum K. Wright</a> for a good model.</p>
-
-</div> <!-- alphas-betas -->
-
</div> <!-- release-stabilization -->
<div class="h2" id="tarball-signing">
